diff options
Diffstat (limited to 'results/classifier/118/graphic')
587 files changed, 39899 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/1000 b/results/classifier/118/graphic/1000 new file mode 100644 index 000000000..32721e157 --- /dev/null +++ b/results/classifier/118/graphic/1000 @@ -0,0 +1,34 @@ +graphic: 0.959 +arm: 0.958 +mistranslation: 0.955 +architecture: 0.786 +semantic: 0.783 +performance: 0.697 +device: 0.694 +network: 0.691 +x86: 0.636 +user-level: 0.599 +assembly: 0.544 +i386: 0.533 +socket: 0.525 +vnc: 0.448 +debug: 0.443 +ppc: 0.425 +virtual: 0.393 +register: 0.364 +permissions: 0.361 +PID: 0.337 +boot: 0.328 +risc-v: 0.323 +peripherals: 0.295 +TCG: 0.277 +VMM: 0.274 +files: 0.229 +kernel: 0.222 +hypervisor: 0.194 +KVM: 0.153 + +Can qemu support different core on one machine? +Description of problem: +I want to build a machine, including three core which is different types, arm Cortex-M3 core, cortex-m33 core, contex-a53 core, communicate through mailbox. I checked the current implementation of QEMU and saw that a machine uses a core, such as mps2.c virt.c . I want to know whether the QEMU strategy supports different types of cores on one machine and can communicate with each other. +Thanks. diff --git a/results/classifier/118/graphic/1003 b/results/classifier/118/graphic/1003 new file mode 100644 index 000000000..c91c9a59a --- /dev/null +++ b/results/classifier/118/graphic/1003 @@ -0,0 +1,51 @@ +graphic: 0.881 +boot: 0.856 +device: 0.786 +performance: 0.680 +register: 0.679 +architecture: 0.673 +x86: 0.594 +semantic: 0.575 +PID: 0.551 +vnc: 0.520 +hypervisor: 0.513 +mistranslation: 0.491 +debug: 0.447 +i386: 0.411 +KVM: 0.388 +permissions: 0.357 +user-level: 0.297 +ppc: 0.245 +peripherals: 0.203 +VMM: 0.194 +network: 0.135 +risc-v: 0.123 +kernel: 0.122 +TCG: 0.107 +arm: 0.094 +socket: 0.075 +assembly: 0.026 +files: 0.016 +virtual: 0.012 + +"Cannot allocate memory" when boots a VM > 1026GB memory with -accel kvm +Description of problem: +I can boot an empty VM using command `qemu-system-x86_64 -m 1026G -accel kvm -vnc :1` or `qemu-system-x86_64 -m 8T -vnc :1` + +But when I use `qemu-system-x86_64 -m 1027G -accel kvm -vnc :1`, it will not boot: + +``` +root@debian11:~# qemu-system-x86_64 -m 1027G -accel kvm -vnc :1 +qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=1, start=0x100000000, size=0x10000000000: Cannot allocate memory +kvm_set_phys_mem: error registering slot: Cannot allocate memory +Aborted +``` + +Which means, with `-accel kvm`, it only can boot a VM which memory <= 1026G, but without these args, it can boot whatever you want. +Steps to reproduce: +1. sysctl vm.overcommit_memory=1 # enable overcommit first +2. qemu-system-x86_64 -m 1027G -accel kvm -vnc :1 +Additional information: +The qemu I use is compiled from the latest source, not the package provided by debian. + +Hardware is `PowerEdge R630` with `E5-2630 v4` * 2, 128G physical RAM. diff --git a/results/classifier/118/graphic/1004 b/results/classifier/118/graphic/1004 new file mode 100644 index 000000000..e4f104d13 --- /dev/null +++ b/results/classifier/118/graphic/1004 @@ -0,0 +1,39 @@ +graphic: 0.985 +i386: 0.981 +device: 0.858 +virtual: 0.809 +performance: 0.747 +architecture: 0.717 +mistranslation: 0.586 +VMM: 0.511 +debug: 0.491 +semantic: 0.405 +PID: 0.390 +boot: 0.355 +x86: 0.340 +register: 0.281 +hypervisor: 0.254 +vnc: 0.241 +socket: 0.185 +arm: 0.172 +network: 0.160 +KVM: 0.134 +files: 0.129 +ppc: 0.127 +kernel: 0.117 +permissions: 0.109 +user-level: 0.109 +TCG: 0.094 +peripherals: 0.046 +risc-v: 0.040 +assembly: 0.030 + +qemu-system-i386 peggs 100% host CPU +Description of problem: +Before the guest OS even starts up, the host CPU eggs at 100%. +Steps to reproduce: +1. Start any VM using qemu-system-i386 +2. On Ubuntu use Virt Manager or command line. +3. On macOS use UTM. +Additional information: + diff --git a/results/classifier/118/graphic/1008 b/results/classifier/118/graphic/1008 new file mode 100644 index 000000000..5bdbff2ab --- /dev/null +++ b/results/classifier/118/graphic/1008 @@ -0,0 +1,50 @@ +graphic: 0.985 +x86: 0.963 +i386: 0.962 +architecture: 0.941 +kernel: 0.921 +hypervisor: 0.876 +virtual: 0.869 +device: 0.818 +semantic: 0.798 +debug: 0.796 +PID: 0.749 +performance: 0.747 +KVM: 0.715 +VMM: 0.690 +vnc: 0.683 +risc-v: 0.627 +ppc: 0.561 +register: 0.547 +permissions: 0.513 +TCG: 0.493 +files: 0.483 +user-level: 0.478 +socket: 0.464 +boot: 0.461 +mistranslation: 0.406 +network: 0.397 +arm: 0.325 +assembly: 0.283 +peripherals: 0.259 + +nested virtualisation with old host kernel, qemu 7.0.0 broken +Description of problem: +``` +$ qemu-system-x86_64 -enable-kvm -nographic +qemu-system-x86_64: error: failed to set MSR 0xc0000104 to 0x100000000 +qemu-system-x86_64: ../target/i386/kvm/kvm.c:2996: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +Aborted (core dumped) + +$ +``` +Steps to reproduce: +1. (hardware) Host 1 running kernel 5.10 with nested kvm enabled +2. (virtual) Host 2, with qemu 7.0.0 installed +3. In the inner/virtual host, run: `qemu-system-x86 -enable-kvm -nographic` +Additional information: +It is fixed by using either a more up-to-date kernel version on the hardware/outer host (5.17.x for example), or by reverting to qemu 6.2.0 in the virtual/inner host. + +I have also reproduced this with latest qemu master, commit 731340813fdb4cb8339edb8630e3f923b7d987ec. + +**Reverting commit 3e4546d5bd38a1e98d4bd2de48631abf0398a3a2 also fixes the issue.** diff --git a/results/classifier/118/graphic/1017 b/results/classifier/118/graphic/1017 new file mode 100644 index 000000000..d008cd32f --- /dev/null +++ b/results/classifier/118/graphic/1017 @@ -0,0 +1,43 @@ +graphic: 0.980 +device: 0.952 +architecture: 0.840 +boot: 0.805 +register: 0.803 +PID: 0.800 +performance: 0.790 +KVM: 0.767 +hypervisor: 0.722 +mistranslation: 0.713 +VMM: 0.699 +socket: 0.691 +virtual: 0.687 +debug: 0.615 +arm: 0.613 +semantic: 0.587 +network: 0.543 +ppc: 0.529 +vnc: 0.517 +permissions: 0.501 +risc-v: 0.493 +files: 0.487 +TCG: 0.469 +user-level: 0.440 +kernel: 0.388 +assembly: 0.380 +peripherals: 0.373 +i386: 0.290 +x86: 0.269 + +Qemu Windows 10 restart bluescreen +Description of problem: +after shutting down qemu VM box and open some system programs on Host System, getting Bluescreen +with following issue - Memory Manangement or shutting down you Host system, getting bluescreen. +Only after stoppingh using qemu vm reboot system. +Steps to reproduce: +1. start qemu vm, ty get some operations +1. then stop the qemu vm via console comands +1. rebooting or restarting Host system +1. by shutting down, you get Bluescreen +2. +Additional information: + diff --git a/results/classifier/118/graphic/1019 b/results/classifier/118/graphic/1019 new file mode 100644 index 000000000..0e42901fa --- /dev/null +++ b/results/classifier/118/graphic/1019 @@ -0,0 +1,43 @@ +graphic: 0.877 +device: 0.836 +architecture: 0.791 +network: 0.791 +PID: 0.742 +semantic: 0.693 +socket: 0.690 +risc-v: 0.620 +ppc: 0.605 +vnc: 0.571 +performance: 0.551 +mistranslation: 0.487 +peripherals: 0.471 +debug: 0.400 +i386: 0.395 +assembly: 0.394 +boot: 0.393 +VMM: 0.391 +register: 0.387 +permissions: 0.382 +x86: 0.343 +kernel: 0.342 +arm: 0.340 +user-level: 0.336 +TCG: 0.335 +hypervisor: 0.311 +files: 0.286 +virtual: 0.249 +KVM: 0.014 + +Cannot create a shared directory between Ubuntu 20.04 host and (sparc) NetBSD 8.2 guest +Description of problem: +I am currently trying to set up a shared directory between the Ubuntu 20.04 LTS host and the QEMU guest. However, the error messages that I receive from QEMU immediately are the following, but unfortunately I don't know the proper way to do this given the host and guest OS. +``` +qemu-system-sparc: warning: hub port hub0port1 has no peer +qemu-system-sparc: warning: hub 0 with no nics +qemu-system-sparc: warning: netdev hub0port1 has no peer +qemu-system-sparc: warning: requested NIC (#net276, model virtio) was not created (not supported by this machine?) +``` +Steps to reproduce: +1. Installed `samba` on the host with `sudo apt install samba` +2. Created `/home/rflint/shared_dir` on the host +3. Ran the command indicated at the top of the page. diff --git a/results/classifier/118/graphic/1020 b/results/classifier/118/graphic/1020 new file mode 100644 index 000000000..6ea6bc2e2 --- /dev/null +++ b/results/classifier/118/graphic/1020 @@ -0,0 +1,46 @@ +graphic: 0.948 +device: 0.787 +files: 0.752 +semantic: 0.745 +PID: 0.619 +vnc: 0.608 +ppc: 0.564 +debug: 0.489 +risc-v: 0.471 +mistranslation: 0.464 +socket: 0.453 +performance: 0.415 +VMM: 0.412 +permissions: 0.368 +user-level: 0.362 +boot: 0.348 +TCG: 0.329 +network: 0.324 +arm: 0.319 +kernel: 0.311 +peripherals: 0.273 +register: 0.215 +architecture: 0.213 +KVM: 0.193 +assembly: 0.185 +i386: 0.182 +virtual: 0.153 +hypervisor: 0.099 +x86: 0.051 + +Display mode 0x6 doubles lines +Description of problem: +When developing https://github.com/korneliuszo/ne2000xt I've occured problem with double lines in mode 0x06 of VGA display, problem doesn't exist in mode 0x05 +Steps to reproduce: +1. Call int 0x10, to setup video mode +2. put data into video ram (./cga.py -i 192.168.1.102 -I ~/a.png) +3. bad display +Additional information: +Bad display: + + +Same data, but in mode 0x05 + + +Same script as in bad display but run under 86Box + diff --git a/results/classifier/118/graphic/1024275 b/results/classifier/118/graphic/1024275 new file mode 100644 index 000000000..b3bfd435f --- /dev/null +++ b/results/classifier/118/graphic/1024275 @@ -0,0 +1,49 @@ +graphic: 0.865 +device: 0.712 +socket: 0.643 +ppc: 0.626 +network: 0.620 +semantic: 0.577 +performance: 0.572 +kernel: 0.532 +architecture: 0.520 +mistranslation: 0.513 +debug: 0.439 +user-level: 0.410 +TCG: 0.410 +files: 0.410 +arm: 0.406 +register: 0.405 +vnc: 0.392 +i386: 0.381 +risc-v: 0.369 +boot: 0.362 +PID: 0.336 +x86: 0.321 +permissions: 0.301 +VMM: 0.290 +hypervisor: 0.268 +peripherals: 0.267 +virtual: 0.221 +KVM: 0.196 +assembly: 0.109 + +bad iteraction between -daemonize and -nographic + + $ qemu -daemonize -nographic + $ _ + +After this, the terminal is switched to some weird mode, not processing cr/lf, and not showing the characters being typed (it is fixable by using `stty sane'). + +Something is seriously wrong here: When -daemonize is given, qemu not touch tty parameters at all. + +Thanks, + +/mjt + +FWIW, it has been present at least since version 0.10 of qemu, and still present in current 1.1 version. + +According to the Debian bug tracker, this has been fixed with this upstream commit: +http://git.qemu.org/?p=qemu.git;a=commit;h=ab51b1d568e02c80b1abf9016bda3a86dc1db389 +... so let's close this now. + diff --git a/results/classifier/118/graphic/1025 b/results/classifier/118/graphic/1025 new file mode 100644 index 000000000..d242ff2b9 --- /dev/null +++ b/results/classifier/118/graphic/1025 @@ -0,0 +1,33 @@ +graphic: 0.850 +files: 0.784 +device: 0.762 +semantic: 0.729 +network: 0.714 +mistranslation: 0.471 +socket: 0.444 +architecture: 0.440 +kernel: 0.408 +VMM: 0.406 +performance: 0.384 +boot: 0.372 +arm: 0.360 +register: 0.356 +ppc: 0.346 +i386: 0.272 +vnc: 0.259 +debug: 0.233 +PID: 0.231 +permissions: 0.223 +KVM: 0.169 +risc-v: 0.162 +hypervisor: 0.159 +TCG: 0.152 +x86: 0.150 +assembly: 0.144 +user-level: 0.101 +peripherals: 0.080 +virtual: 0.051 + +qemu-img create will silently overwrite existing image +Description of problem: +If file exists, it is silently overwritten, causing loss of data. oups. diff --git a/results/classifier/118/graphic/1030807 b/results/classifier/118/graphic/1030807 new file mode 100644 index 000000000..59105c4a9 --- /dev/null +++ b/results/classifier/118/graphic/1030807 @@ -0,0 +1,88 @@ +graphic: 0.894 +peripherals: 0.812 +register: 0.802 +kernel: 0.800 +arm: 0.777 +user-level: 0.769 +socket: 0.766 +architecture: 0.764 +files: 0.758 +device: 0.757 +permissions: 0.754 +network: 0.753 +hypervisor: 0.736 +virtual: 0.730 +performance: 0.721 +semantic: 0.719 +boot: 0.715 +ppc: 0.712 +mistranslation: 0.709 +assembly: 0.699 +PID: 0.690 +debug: 0.685 +TCG: 0.640 +vnc: 0.627 +risc-v: 0.612 +KVM: 0.571 +x86: 0.566 +VMM: 0.538 +i386: 0.463 + +PCI host bridge should ignore 1- and 2-byte I/O accesses + +In PCI there are two IO modes. Deprecated Mode2 that uses single byte IO and Mode1 that uses 4byte IO. +According to the spec a host bridge that supports Mode1 should ignore all IO that is not 4bytes. + +> Anytime a host bridge sees a full DWORD I/O write from the host to +> CONFIG_ADDRESS, the bridge must latch the data into its CONFIG_ADDRESS +> register. On full DWORD I/O reads to CONFIG_ADDRESS, the bridge must return the +> data in CONFIG_ADDRESS. Any other types of accesses to this address (non-DWORD) +> have no effect on CONFIG_ADDRESS and are executed as normal I/O transactions on +> the PCI bus. Therefore, the only I/O Space consumed by this register is a DWORD at the +> given address. I/O devices that share the same address but use BYTE or WORD registers +> are not affected because their transactions will pass through the host bridge unchanged. + +In qemu the host bridge will accept 1-, 2-, and 4-byte reads/writes. That breakes plan9 guests that do not use the bios to access the PCI config space. + +have a look at: +http://code.google.com/p/plan9front/source/browse/sys/src/9/pc/pci.c + +In Lines 960-967 the check for PCI Mode1 is done. This check assumes that the 4-byte write at line 961 succeeds and the single byte write at 962 is ignored. +On qemu line 962 will not be ignored and the test in line 963 will fail. +The plan9 kernel will fall back to Mode2 which does not work. +The result is that the guest will not see any PCI devices. + +I do not really have an image that you guys could quickly check this with, but i could prepare one if need be. +An easy way to reproduce this in linux would be to stick an outb between those two lines from pci_check_type1(void). + +> outl(0x80000000, 0xCF8); ++ outb0x01, 0xcfb); +> if (inl(0xCF8) == 0x80000000 && pci_sanity_check(&pci_direct_conf1)) { + +I did not try this but i guess on real hardware the linux kernel would still work while it would not work anymore on qemu. + +I tried to come up with a patch but did not find a quick solution. I found that in hw/piic_pci.c sysbus_add_io is used which will register read/write functions for 1, 2, and 4 bytes. This is done in ioport.c ioport_register. I guess if i provided a patch you guys might not like it :). So i figured i should report the bug, let me know if you need any additional information. + +I tried the following quick fix but the BIOS does not seem to like that. + + + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +Cc'ing Julia (can't find her on Launchpad) because this looks +similar to a bug she has been tracking. + +On 8/7/20 10:08 AM, Thomas Huth wrote: +> Looking through old bug tickets... is this still an issue with the +> latest version of QEMU? Or could we close this ticket nowadays? +> +> +> ** Changed in: qemu +> Status: New => Incomplete +> + + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1036 b/results/classifier/118/graphic/1036 new file mode 100644 index 000000000..7f8758efa --- /dev/null +++ b/results/classifier/118/graphic/1036 @@ -0,0 +1,45 @@ +graphic: 0.970 +x86: 0.883 +device: 0.793 +architecture: 0.772 +semantic: 0.682 +performance: 0.490 +vnc: 0.409 +i386: 0.402 +PID: 0.392 +ppc: 0.392 +kernel: 0.392 +network: 0.389 +debug: 0.368 +risc-v: 0.335 +register: 0.328 +boot: 0.318 +socket: 0.312 +permissions: 0.305 +mistranslation: 0.298 +files: 0.274 +peripherals: 0.248 +user-level: 0.212 +arm: 0.205 +hypervisor: 0.170 +virtual: 0.118 +VMM: 0.117 +TCG: 0.115 +assembly: 0.085 +KVM: 0.064 + +QEMU immediately exits when combining a GL-enabled SDL display with SPICE +Description of problem: +Running QEMU with the given command line results in QEMU immediately exiting with this line being printed, and no other output: + +``` +qemu-system-x86_64: Display spice is incompatible with the GL context +``` + +I am unsure whether this is a supported mode of setting up QEMU, but QEMU 6.2.0 ran just fine with it (or, to be more precise, it wasn't an issue until ac32b2fff127843355b4f7e7ac9f93dd4a395adf). + +The issue does not happen with `-display sdl,gl=off`, as GL is presumably not involved at all in that case. +Steps to reproduce: +1. Run `./qemu-system-x86_64 -display sdl,gl=on -spice port=5930`. +Additional information: +This issue has been reproduced on other distributions, including Ubuntu 20.04 and Ubuntu 22.04. diff --git a/results/classifier/118/graphic/1040 b/results/classifier/118/graphic/1040 new file mode 100644 index 000000000..b5c819692 --- /dev/null +++ b/results/classifier/118/graphic/1040 @@ -0,0 +1,36 @@ +graphic: 0.986 +device: 0.857 +performance: 0.826 +mistranslation: 0.818 +virtual: 0.816 +risc-v: 0.812 +socket: 0.799 +VMM: 0.785 +vnc: 0.760 +semantic: 0.758 +register: 0.734 +hypervisor: 0.719 +network: 0.716 +files: 0.665 +architecture: 0.636 +kernel: 0.615 +PID: 0.599 +arm: 0.569 +ppc: 0.525 +permissions: 0.518 +TCG: 0.505 +x86: 0.473 +debug: 0.448 +KVM: 0.434 +boot: 0.413 +i386: 0.413 +user-level: 0.342 +peripherals: 0.330 +assembly: 0.286 + +Windows Server 2016 VM totally freezes spontaneously during the day a couple of times for 1-5 minutes. There is no any logs in it during the freeze +Description of problem: +Windows Server 2016 VM totally freezes spontaneously during the day a couple of times for 1-5 minutes. There is no any logs inside VM during the freeze. Timestamp of the last log written into journal is right before the freeze and the pretty next log is right after the freeze is gone. Looks like "black hole". No ping from from the host toward the VM. There is no way to connect to the VM even via spice on virt-manager as well. Seems like the VM is suspending. Htop on the host during the time of the freeze shows 100% load of all eight cores dedicated to the VM. But the host system is available and reachable, the lxc's inside this host is available and reachable as well. + + + diff --git a/results/classifier/118/graphic/1041 b/results/classifier/118/graphic/1041 new file mode 100644 index 000000000..62ca494a7 --- /dev/null +++ b/results/classifier/118/graphic/1041 @@ -0,0 +1,61 @@ +graphic: 0.899 +architecture: 0.897 +assembly: 0.874 +mistranslation: 0.846 +x86: 0.790 +kernel: 0.682 +device: 0.653 +performance: 0.595 +peripherals: 0.484 +files: 0.458 +PID: 0.418 +debug: 0.412 +network: 0.412 +semantic: 0.396 +socket: 0.342 +ppc: 0.330 +vnc: 0.291 +permissions: 0.279 +hypervisor: 0.278 +user-level: 0.245 +virtual: 0.218 +register: 0.197 +boot: 0.197 +arm: 0.195 +risc-v: 0.154 +VMM: 0.148 +TCG: 0.120 +KVM: 0.091 +i386: 0.031 + +x86_64 Auxillary vector reports platform as i686 which doesn't match the linux kernel +Description of problem: +Based on the kernel source in the auxiliary vector AT_PLATFORM should be `x86_64` (confirmed by running outside qemu). However qemu sets it to `i686`. + +This was originally reported with docker-for-mac, but was reduced on `x86_64` which is why it is pointless +Steps to reproduce: +1. Compile the following for x86_64 (statically if you don't want have an x86_64 dynamic linker) (code originally from https://stackoverflow.com/questions/26520163/accessing-auxiliary-vectors-c) + +``` +#include <stdio.h> +#include <elf.h> + +int main(int argc, char** argv, char* envp[]) { + Elf64_auxv_t *auxv; + while(*envp++ != NULL); + + /*from stack diagram above: *envp = NULL marks end of envp*/ + int i = 0 ; + for (auxv = (Elf64_auxv_t *)envp; auxv->a_type != AT_NULL; auxv++) + /* auxv->a_type = AT_NULL marks the end of auxv */ + { + if( auxv->a_type == AT_PLATFORM) + printf("AT_PLATFORM is: %s\n", ((char*)auxv->a_un.a_val)); + } +} +``` +2. Run with `qemu-x86_64-static` +3. See `AT_PLATFORM is: i686` +4. Compare to "real" x86_64 bit system which gives `AT_PLATFORM is: x86_64` +Additional information: +I think that adding `#define ELF_PLATFORM "x86_64"` [here](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c#L134) should work (but I don't fully understand the code). Otherwise we just end up getting the 32-bit case. diff --git a/results/classifier/118/graphic/1046 b/results/classifier/118/graphic/1046 new file mode 100644 index 000000000..ef09b2c6d --- /dev/null +++ b/results/classifier/118/graphic/1046 @@ -0,0 +1,42 @@ +graphic: 0.937 +performance: 0.877 +device: 0.868 +arm: 0.834 +KVM: 0.638 +architecture: 0.584 +hypervisor: 0.581 +x86: 0.490 +VMM: 0.454 +PID: 0.409 +permissions: 0.406 +debug: 0.395 +semantic: 0.384 +mistranslation: 0.333 +vnc: 0.331 +virtual: 0.311 +network: 0.305 +register: 0.303 +risc-v: 0.279 +socket: 0.255 +i386: 0.253 +kernel: 0.253 +peripherals: 0.231 +boot: 0.215 +user-level: 0.180 +ppc: 0.157 +TCG: 0.134 +assembly: 0.081 +files: 0.051 + +Using more than 2G of RAM on armv7l guest with RPI4 +Description of problem: +I was able to run my armv7l guest on RPI4 8G using qemu 6.2, but on 7.0 it doesn't work: +`qemu-kvm: Addressing limited to 32 bits, but memory exceeds it by 3221225472 bytes`. + +The only reference I found is this issue: https://gitlab.com/qemu-project/qemu/-/issues/903 +Steps to reproduce: +1. `-M virt,highmem=off,gic-version=host,accel=kvm` +2. `-cpu host,aarch64=off` +3. `-m 6G` +Additional information: + diff --git a/results/classifier/118/graphic/1051 b/results/classifier/118/graphic/1051 new file mode 100644 index 000000000..895b2883e --- /dev/null +++ b/results/classifier/118/graphic/1051 @@ -0,0 +1,31 @@ +graphic: 0.963 +semantic: 0.930 +mistranslation: 0.829 +performance: 0.800 +TCG: 0.789 +device: 0.740 +register: 0.530 +network: 0.513 +files: 0.454 +vnc: 0.382 +assembly: 0.355 +virtual: 0.352 +boot: 0.333 +architecture: 0.288 +kernel: 0.285 +permissions: 0.246 +hypervisor: 0.245 +risc-v: 0.228 +user-level: 0.217 +arm: 0.187 +peripherals: 0.122 +socket: 0.099 +debug: 0.098 +ppc: 0.067 +VMM: 0.046 +PID: 0.028 +KVM: 0.018 +x86: 0.016 +i386: 0.013 + +or1k tcg SIGILL diff --git a/results/classifier/118/graphic/1058 b/results/classifier/118/graphic/1058 new file mode 100644 index 000000000..ac87439ad --- /dev/null +++ b/results/classifier/118/graphic/1058 @@ -0,0 +1,38 @@ +graphic: 0.965 +architecture: 0.952 +device: 0.900 +boot: 0.864 +arm: 0.793 +socket: 0.744 +ppc: 0.655 +network: 0.646 +virtual: 0.603 +vnc: 0.603 +risc-v: 0.541 +semantic: 0.499 +debug: 0.492 +PID: 0.489 +performance: 0.480 +x86: 0.468 +permissions: 0.359 +kernel: 0.353 +register: 0.324 +TCG: 0.301 +VMM: 0.289 +user-level: 0.285 +mistranslation: 0.210 +i386: 0.181 +files: 0.145 +hypervisor: 0.088 +peripherals: 0.083 +assembly: 0.055 +KVM: 0.007 + +NetBSD Sparc 8.2 OS doesn't seem to accept keyboard input (-nographic) +Description of problem: +The NetBSD appears to boot to the login prompt successfully, but when the login prompt appears, the system doesn't appear to recognize keyboard input and so I cannot login (I can't seem to boot into single user mode for the same reason). I can see the characters being typed on the terminal, but pressing the Enter key to submit input results in nothing. + +I've confirmed that this is an issue with NetBSD because I also attempted to spin up a Solaris 8 VM and a Solaris 2.6 VM with the `-nographic` flag turned on, and I was able to log in and interact with both of those virtual machines. +Steps to reproduce: +1. Use RHEL 8.6 as the base OS (**Update:** I've discovered that this error occurs under a different host OS too (Ubuntu 20.04 LTS in my case) +2. Start the NetBSD VM running the command as specified above diff --git a/results/classifier/118/graphic/1059 b/results/classifier/118/graphic/1059 new file mode 100644 index 000000000..8c6edcf33 --- /dev/null +++ b/results/classifier/118/graphic/1059 @@ -0,0 +1,40 @@ +graphic: 0.978 +device: 0.793 +network: 0.565 +files: 0.502 +PID: 0.454 +arm: 0.454 +semantic: 0.402 +performance: 0.385 +socket: 0.384 +risc-v: 0.378 +debug: 0.370 +ppc: 0.320 +vnc: 0.314 +boot: 0.264 +user-level: 0.261 +architecture: 0.250 +permissions: 0.199 +mistranslation: 0.188 +register: 0.167 +VMM: 0.140 +peripherals: 0.135 +i386: 0.129 +TCG: 0.098 +x86: 0.091 +kernel: 0.087 +virtual: 0.082 +hypervisor: 0.068 +assembly: 0.048 +KVM: 0.036 + +qemu: uncaught target signal 6 (Aborted) - core dumped Issue +Description of problem: +When we are trying to use the docker images which is using Qemu internally in mac Os then we are getting the qemu: uncaught target signal 6 (Aborted) - core dumped Issue +Steps to reproduce: +1. https://botfront.io/docs/installation/local-machine install in local machine +2. run bot front run +3. Go to the docker dashboard and open the botfront-rasa. +4.  +Additional information: +Looking forward to get some updates regarding how we can solve this or any hack we can apply here. Thanks in advance. diff --git a/results/classifier/118/graphic/1063 b/results/classifier/118/graphic/1063 new file mode 100644 index 000000000..2f190b78b --- /dev/null +++ b/results/classifier/118/graphic/1063 @@ -0,0 +1,39 @@ +graphic: 0.980 +virtual: 0.937 +device: 0.919 +vnc: 0.797 +performance: 0.790 +ppc: 0.771 +boot: 0.744 +PID: 0.726 +semantic: 0.658 +architecture: 0.657 +register: 0.627 +files: 0.612 +mistranslation: 0.606 +risc-v: 0.528 +socket: 0.502 +debug: 0.499 +permissions: 0.481 +network: 0.480 +VMM: 0.476 +TCG: 0.432 +hypervisor: 0.325 +kernel: 0.289 +arm: 0.275 +user-level: 0.242 +x86: 0.238 +peripherals: 0.225 +i386: 0.202 +KVM: 0.191 +assembly: 0.142 + +qemu: could not load PC BIOS 'bios-256k.bin' +Description of problem: +I cloned latest QEMU and build in Ubuntu 18.04, when I run QEMU to start a vm, it tells me `could not load PC BIOS 'bios-256k.bin' + + +Steps to reproduce: +1. Clone latest QEMU in Ubuntu18.04 +2. build QEMU +3. Use QEMU and libvirt to start a virtual machine. diff --git a/results/classifier/118/graphic/1068 b/results/classifier/118/graphic/1068 new file mode 100644 index 000000000..72270dced --- /dev/null +++ b/results/classifier/118/graphic/1068 @@ -0,0 +1,41 @@ +graphic: 0.976 +VMM: 0.946 +vnc: 0.920 +virtual: 0.919 +kernel: 0.914 +device: 0.907 +boot: 0.906 +socket: 0.801 +architecture: 0.771 +network: 0.759 +debug: 0.752 +PID: 0.732 +semantic: 0.706 +risc-v: 0.702 +permissions: 0.672 +files: 0.634 +KVM: 0.632 +performance: 0.620 +hypervisor: 0.618 +register: 0.612 +TCG: 0.541 +x86: 0.528 +ppc: 0.505 +arm: 0.466 +i386: 0.423 +mistranslation: 0.348 +user-level: 0.290 +assembly: 0.207 +peripherals: 0.183 + +VMs stuck loading Kernel "Freeing unused Kernel image (initmem) memory" with host running Vanilla Kernel >= 5.18.0 +Description of problem: +The VMs are stuck after "Freeing unused Kernel image (initmem) memory" +See attached screen recording. +Rebooting the host with Kernel 5.17.13 solves the problem. +Steps to reproduce: +1. Boot host with Kernel >= 5.18.0 +2. Start VM +Additional information: +[bug.log](/uploads/faa14ac0bf84a21beb2ffeeb650df4b9/bug.log) +[qemu-libvirt-host-kernel-5.18.2.mkv](/uploads/87a064f171833e9fb3d46fd3ece32152/qemu-libvirt-host-kernel-5.18.2.mkv) diff --git a/results/classifier/118/graphic/1075 b/results/classifier/118/graphic/1075 new file mode 100644 index 000000000..702aada2c --- /dev/null +++ b/results/classifier/118/graphic/1075 @@ -0,0 +1,46 @@ +x86: 0.999 +architecture: 0.982 +graphic: 0.974 +ppc: 0.957 +device: 0.872 +permissions: 0.867 +performance: 0.852 +network: 0.844 +socket: 0.729 +PID: 0.698 +mistranslation: 0.688 +TCG: 0.679 +vnc: 0.678 +files: 0.670 +VMM: 0.664 +semantic: 0.564 +risc-v: 0.556 +kernel: 0.552 +arm: 0.522 +debug: 0.522 +peripherals: 0.501 +user-level: 0.486 +register: 0.478 +boot: 0.472 +i386: 0.449 +hypervisor: 0.366 +virtual: 0.247 +KVM: 0.150 +assembly: 0.045 + +Unable to create a cluster using ppc64le specific kind binary on x86 host architecture +Description of problem: + +Steps to reproduce: +1. docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +2. wget https://github.com/kubernetes-sigs/kind/releases/download/v0.14.0/kind-linux-ppc64le +3. chmod u+x kind-linux-ppc64le +4. curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/ppc64le/kubectl +5. chmod +x kubectl +6. sudo cp kubectl /usr/local/bin/ +7. KUBECONFIG="${HOME}/kind-test-config" +8. export KUBECONFIG +9. ./kind-linux-ppc64le create cluster --image quay.io/mayurwaghmode111/node-ppc64le:ppc64le -v=3 --wait 1m --retain +10. ./kind-linux-ppc64le export logs +Additional information: + diff --git a/results/classifier/118/graphic/1081416 b/results/classifier/118/graphic/1081416 new file mode 100644 index 000000000..ec2f4ad91 --- /dev/null +++ b/results/classifier/118/graphic/1081416 @@ -0,0 +1,128 @@ +graphic: 0.920 +permissions: 0.887 +user-level: 0.879 +architecture: 0.876 +register: 0.873 +performance: 0.841 +ppc: 0.807 +device: 0.804 +peripherals: 0.798 +boot: 0.793 +files: 0.780 +risc-v: 0.778 +debug: 0.776 +arm: 0.772 +PID: 0.772 +network: 0.768 +semantic: 0.762 +assembly: 0.758 +socket: 0.758 +x86: 0.756 +virtual: 0.749 +TCG: 0.740 +hypervisor: 0.725 +vnc: 0.719 +mistranslation: 0.718 +KVM: 0.703 +kernel: 0.687 +VMM: 0.566 +i386: 0.554 + +Qemu 1.2.0 crashes when using tcp serial console and GRUB boots + +When booting OpenWRT Attitude Adjustement ( http://downloads.openwrt.org/attitude_adjustment/12.09-beta2/x86/generic/openwrt-x86-generic-combined-ext4.img.gz ) with this command line: +qemu-system-x86_64 -serial tcp:127.0.0.1:4444 -hda openwrt-x86-generic-combined-ext4.img + +Qemu crashes as soon as GRUB starts, after network cards start. + +*** buffer overflow detected ***: /usr/bin/qemu-system-x86_64 terminated +======= Backtrace: ========= +/usr/lib/libc.so.6(__fortify_fail+0x37)[0x7ffff45f2ad7] +/usr/lib/libc.so.6(+0xf9bb0)[0x7ffff45f0bb0] +/usr/lib/libc.so.6(+0xfba47)[0x7ffff45f2a47] +/usr/bin/qemu-system-x86_64[0x46a628] +/usr/bin/qemu-system-x86_64[0x4e8a14] +/usr/bin/qemu-system-x86_64[0x4e802b] +/usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7ffff4518725] +/usr/bin/qemu-system-x86_64[0x40d949] + + +Here is a GDB backtrace: + +Program received signal SIGABRT, Aborted. +0x00007ffff452bfa5 in raise () from /usr/lib/libc.so.6 +(gdb) bt +#0 0x00007ffff452bfa5 in raise () from /usr/lib/libc.so.6 +#1 0x00007ffff452d428 in abort () from /usr/lib/libc.so.6 +#2 0x00007ffff456acfb in __libc_message () from /usr/lib/libc.so.6 +#3 0x00007ffff45f2ad7 in __fortify_fail () from /usr/lib/libc.so.6 +#4 0x00007ffff45f0bb0 in __chk_fail () from /usr/lib/libc.so.6 +#5 0x00007ffff45f2a47 in __fdelt_warn () from /usr/lib/libc.so.6 +#6 0x000000000046a628 in qemu_iohandler_poll (readfds=0xdb7da0 <rfds>, + writefds=0xdb7e20 <wfds>, xfds=0x6, xfds@entry=0xdb7ea0 <xfds>, ret=-1, + ret@entry=1) at iohandler.c:121 +#7 0x00000000004e8a14 in main_loop_wait (nonblocking=<optimized out>) + at main-loop.c:497 +#8 0x00000000004e802b in main_loop () + at /usr/src/aur/qemu/src/qemu-1.2.0/vl.c:1643 +#9 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) + at /usr/src/aur/qemu/src/qemu-1.2.0/vl.c:3755 +(gdb) + +Here is a more useless dump... + +On Wed, Nov 21, 2012 at 03:14:28AM -0000, Jérôme Poulin wrote: +> When booting OpenWRT Attitude Adjustement ( http://downloads.openwrt.org/attitude_adjustment/12.09-beta2/x86/generic/openwrt-x86-generic-combined-ext4.img.gz ) with this command line: +> qemu-system-x86_64 -serial tcp:127.0.0.1:4444 -hda openwrt-x86-generic-combined-ext4.img +> +> Qemu crashes as soon as GRUB starts, after network cards start. +[...] +> Program received signal SIGABRT, Aborted. +> 0x00007ffff452bfa5 in raise () from /usr/lib/libc.so.6 +> (gdb) bt +> #0 0x00007ffff452bfa5 in raise () from /usr/lib/libc.so.6 +> #1 0x00007ffff452d428 in abort () from /usr/lib/libc.so.6 +> #2 0x00007ffff456acfb in __libc_message () from /usr/lib/libc.so.6 +> #3 0x00007ffff45f2ad7 in __fortify_fail () from /usr/lib/libc.so.6 +> #4 0x00007ffff45f0bb0 in __chk_fail () from /usr/lib/libc.so.6 +> #5 0x00007ffff45f2a47 in __fdelt_warn () from /usr/lib/libc.so.6 +> #6 0x000000000046a628 in qemu_iohandler_poll (readfds=0xdb7da0 <rfds>, +> writefds=0xdb7e20 <wfds>, xfds=0x6, xfds@entry=0xdb7ea0 <xfds>, ret=-1, +> ret@entry=1) at iohandler.c:121 +> #7 0x00000000004e8a14 in main_loop_wait (nonblocking=<optimized out>) +> at main-loop.c:497 +> #8 0x00000000004e802b in main_loop () +> at /usr/src/aur/qemu/src/qemu-1.2.0/vl.c:1643 +> #9 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) +> at /usr/src/aur/qemu/src/qemu-1.2.0/vl.c:3755 + +Can't reproduce on qemu.git/master (1ccbc2851282564308f790753d7158487b6af8e2) or +qemu-system-x86-1.2.0-23.fc18.x86_64. + +I get to the OpenWRT root prompt. + +Please build qemu.git/master from source to verify whether this issue +still exists: + + $ git clone git://git.qemu-project.org/qemu.git + $ cd qemu + $ ./configure --target-list=x86_64-softmmu && make + $ x86_64-softmmu/qemu-system-x86_64 -serial tcp:127.0.0.1:4444 -hda openwrt-x86-generic-combined-ext4.img + +Note that if you want to connect to the serial port you should use +-serial tcp:127.0.0.1:4444,server. The command-line you specified tries +to connect to 127.0.0.1:4444 as a client instead of listening as a +server. + +Thanks, +Stefan + + +I'm seeing this too. If someone cares to tell me how I get a core file from qemu-under-libvirt I will do that and report back on debugging. + +(fairly sure it's in the iohandler based on a manual check of the symbols, though) + +Can you still reproduce this issue somehow with the latest version of QEMU (currently v2.9.0)? Otherwise, I think we can close this ticket nowadays... + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1085 b/results/classifier/118/graphic/1085 new file mode 100644 index 000000000..8a0b92309 --- /dev/null +++ b/results/classifier/118/graphic/1085 @@ -0,0 +1,70 @@ +graphic: 0.898 +socket: 0.760 +ppc: 0.722 +register: 0.720 +device: 0.687 +network: 0.677 +files: 0.630 +arm: 0.577 +PID: 0.546 +vnc: 0.525 +debug: 0.524 +semantic: 0.515 +risc-v: 0.504 +performance: 0.491 +architecture: 0.465 +permissions: 0.439 +VMM: 0.438 +boot: 0.437 +user-level: 0.381 +x86: 0.379 +kernel: 0.373 +hypervisor: 0.325 +TCG: 0.323 +mistranslation: 0.288 +KVM: 0.277 +i386: 0.272 +peripherals: 0.252 +assembly: 0.217 +virtual: 0.183 + +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/118/graphic/1089 b/results/classifier/118/graphic/1089 new file mode 100644 index 000000000..c84ec05c6 --- /dev/null +++ b/results/classifier/118/graphic/1089 @@ -0,0 +1,54 @@ +graphic: 0.968 +mistranslation: 0.962 +device: 0.924 +performance: 0.899 +PID: 0.853 +debug: 0.730 +semantic: 0.644 +vnc: 0.631 +risc-v: 0.608 +VMM: 0.603 +permissions: 0.598 +network: 0.597 +register: 0.593 +user-level: 0.591 +i386: 0.577 +assembly: 0.541 +ppc: 0.541 +architecture: 0.535 +x86: 0.522 +kernel: 0.519 +hypervisor: 0.461 +socket: 0.460 +files: 0.447 +TCG: 0.436 +virtual: 0.431 +boot: 0.427 +KVM: 0.418 +peripherals: 0.367 +arm: 0.266 + +when I use memory balloon,the qemu process memory usage is displayed incorrectly +Description of problem: +My vm memory is 4GB,and use the balloon driver,the balloon value is also 4GB. +I run a soft to consume memory in vm,I can see the memory usage rate is 15% in host. When I stop the soft in vm,the memory of free info in host and vm +become normal,but use "top -d 3 -Hp $qemu_pid" to query in host,the memory usage rate is also 15%.I need to modify the balloon value in a smaller values,the memory usage rate will reduce. why? + +Steps to reproduce: +1.run a soft to consume memory in vm,and query top info,the qemu process memory usage:15% + + +2.query free info in host and vm (reduce) + + +3.stop sort in vm + + +4.query free info in host and vm (recover) + + +5.query top info again (also 15%) + + + +6.modify the balloon value in a smaller (modify the balloon value in a smaller values,the memory usage rate will reduce) diff --git a/results/classifier/118/graphic/1090615 b/results/classifier/118/graphic/1090615 new file mode 100644 index 000000000..380f0e30a --- /dev/null +++ b/results/classifier/118/graphic/1090615 @@ -0,0 +1,60 @@ +graphic: 0.903 +virtual: 0.893 +device: 0.857 +semantic: 0.732 +vnc: 0.710 +network: 0.677 +PID: 0.631 +x86: 0.622 +risc-v: 0.608 +mistranslation: 0.580 +files: 0.568 +performance: 0.558 +user-level: 0.552 +socket: 0.517 +arm: 0.515 +register: 0.488 +architecture: 0.485 +i386: 0.483 +boot: 0.447 +VMM: 0.408 +debug: 0.386 +kernel: 0.380 +ppc: 0.347 +assembly: 0.282 +permissions: 0.279 +hypervisor: 0.235 +peripherals: 0.218 +TCG: 0.157 +KVM: 0.019 + + RFE: More info in qemu-img info/check + +Originally filed in Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=861375 + +""" +qemu-img info currently give me info like this: + +image: /home/alex/.local/share/gnome-boxes/images/Fedora 16 +file format: qcow2 +virtual size: 11G (11794287616 bytes) +disk size: 4.5G +cluster_size: 65536 + +In order to figure out the "health" of an image there is some more information I would like: + +in-use disk size - I.e the subset of disk size that is not marked as unused due to e.g. TRIM operations + +amount of compressed clusters. I.e. "is it useful to re-compress the image". + +Fragmentation estimation. + +This would be useful to both sysadmins in general and for automated things like +what we want to do in gnome-boxes: +https://bugzilla.gnome.org/show_bug.cgi?id=685032 +""" + +As mentioned in the original report, qemu-img check currently has fragmentation stats, but only for QED. + +qemu-img check has reported allocated clusters, compressed clusters and fragmentation for qcow2 images since February 2013 (QEMU 1.5). + diff --git a/results/classifier/118/graphic/1091115 b/results/classifier/118/graphic/1091115 new file mode 100644 index 000000000..5e2ee0e6b --- /dev/null +++ b/results/classifier/118/graphic/1091115 @@ -0,0 +1,66 @@ +user-level: 0.958 +i386: 0.957 +graphic: 0.950 +x86: 0.949 +files: 0.905 +architecture: 0.897 +mistranslation: 0.871 +performance: 0.867 +semantic: 0.866 +debug: 0.858 +vnc: 0.843 +PID: 0.834 +virtual: 0.825 +permissions: 0.814 +KVM: 0.809 +register: 0.802 +device: 0.794 +assembly: 0.791 +network: 0.731 +VMM: 0.730 +socket: 0.720 +boot: 0.715 +ppc: 0.686 +risc-v: 0.668 +kernel: 0.665 +hypervisor: 0.657 +TCG: 0.645 +arm: 0.628 +peripherals: 0.600 + +windowsXP install in qemu-system-i386 1.3.0 ends with a BSOD 0x7E in acpi.sys + +These are the commands: +$git checkout v1.3.0 +$./configure --prefix=/home/user/tmp --target-list=i386-softmmu --enable-sdl --disable-curses --disable-vnc --enable-kvm --disable-docs +$make +$make install +In /home/user/tmp directory: +$./bin/qemu-img create imgs/winxp.img 4G +$./bin/qemu-system-i386 imgs/winxp.img -cdrom ~/Downloads/zh-hans_windows_xp_professional_with_service_pack_3_x86_cd_x14-80404.iso + +then it show a bluescreen after a few seconds. +See the attachment for more information, please. + +It works well when checking out v1.2.0. + + + +Same as Bug 1096712 I reported + +It is most likely the seabios bits missing in 1.3.0, namely this change: + + http://git.qemu.org/?p=seabios.git;a=commitdiff;h=f64a472a481784231fbf8541825501df411b11d1 + +You may try this bios file: + + http://git.qemu.org/?p=qemu.git;a=blob;f=pc-bios/bios.bin;h=3910875311ceaed814f902e9e4e7e29cdf340fc6 + +at least it works for me on top of 1.3.0 version, and 1.3.0 without updated bios behaves like you describe. So I'm marking this as "fix comitted" for now, waiting for 1.3.1 release... + +Alternative BIOS works for me with both installed system and installer. + +I have also verified that the BIOS above works with Windows XP (SP2). + +Changing status to "Fix Released" since this should have been included since a couple of releases now. + diff --git a/results/classifier/118/graphic/1096 b/results/classifier/118/graphic/1096 new file mode 100644 index 000000000..b927abe52 --- /dev/null +++ b/results/classifier/118/graphic/1096 @@ -0,0 +1,31 @@ +graphic: 0.861 +device: 0.805 +register: 0.608 +risc-v: 0.602 +performance: 0.580 +network: 0.576 +vnc: 0.524 +files: 0.477 +permissions: 0.419 +boot: 0.408 +assembly: 0.377 +peripherals: 0.362 +semantic: 0.362 +mistranslation: 0.339 +arm: 0.295 +ppc: 0.286 +hypervisor: 0.241 +architecture: 0.236 +virtual: 0.232 +socket: 0.226 +debug: 0.210 +kernel: 0.205 +PID: 0.171 +VMM: 0.161 +user-level: 0.141 +x86: 0.078 +i386: 0.053 +KVM: 0.030 +TCG: 0.023 + +New warning with GCC 13 diff --git a/results/classifier/118/graphic/1099403 b/results/classifier/118/graphic/1099403 new file mode 100644 index 000000000..f061c34d1 --- /dev/null +++ b/results/classifier/118/graphic/1099403 @@ -0,0 +1,44 @@ +x86: 0.965 +graphic: 0.941 +vnc: 0.936 +performance: 0.918 +device: 0.802 +architecture: 0.719 +semantic: 0.695 +VMM: 0.685 +network: 0.668 +hypervisor: 0.589 +ppc: 0.578 +PID: 0.563 +virtual: 0.554 +debug: 0.534 +i386: 0.526 +register: 0.511 +risc-v: 0.494 +permissions: 0.432 +kernel: 0.415 +mistranslation: 0.405 +assembly: 0.394 +boot: 0.367 +socket: 0.360 +peripherals: 0.310 +user-level: 0.296 +TCG: 0.294 +arm: 0.271 +files: 0.206 +KVM: 0.068 + +High CPU utilization in vnc mode + +We start a gentoo guest using ./x86-64-softmmu/qemu-x86-64 -hda <disk>.qcow2 -vnc :6. + +Then we start a vncviewer session to this guest from a remote computer. In this session, we start a video. After starting the video, the CPU utilization of the guest (the qemu-x86-64 process) increases to about 90%. The high CPU utilization persists even after closing the vncviewer session. + +However, the CPU usage while running a video inside a gentoo guest (without a remote computer connecting via vncviewer) is only 20-30%. So we suspect the high CPU usage to be due to the vncserver code running inside QEMU which has to do a lot of work to send the framebuffer updates to the client. + +My question is why does the usage not decrease when the remote vncviewer is disconnected? On simple computers (no virtual guests), the CPU usage of vncserver decreases drastically when the vncviewer client is disconnected. Why does this not happen in the vncserver provided by QEMU (through -vnc :6). + +Triaging old bug tickets ... Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0), or could we close this bug nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1107 b/results/classifier/118/graphic/1107 new file mode 100644 index 000000000..ea08d77f8 --- /dev/null +++ b/results/classifier/118/graphic/1107 @@ -0,0 +1,54 @@ +graphic: 0.942 +files: 0.818 +peripherals: 0.775 +virtual: 0.657 +device: 0.657 +boot: 0.591 +semantic: 0.584 +performance: 0.549 +hypervisor: 0.548 +x86: 0.496 +PID: 0.472 +architecture: 0.446 +i386: 0.429 +user-level: 0.426 +debug: 0.386 +permissions: 0.330 +mistranslation: 0.306 +VMM: 0.299 +ppc: 0.291 +vnc: 0.290 +register: 0.281 +socket: 0.278 +risc-v: 0.276 +network: 0.264 +KVM: 0.234 +kernel: 0.211 +TCG: 0.206 +arm: 0.183 +assembly: 0.160 + +Virtual monitor heads are not "connected" until viewed in a front end +Description of problem: +When you attach a virtual GPU to a guest, qemu appears to only "attach" a virtual monitor to an output port when that virtual display is +viewed using the GUI. For example, when you boot using the above command line, there will be four displays in ```/sys/class/drm/``` on the guest, +```card0-Virtual-1``` through to ```card0-Virtual-4```. In each of these directories, there is an "enabled" file, which contains either +"enabled" or "disabled". These contain "disabled" until you switch tab/view to look at it using the GUI, at which point they change to "enabled". + +This causes a problem for us because Weston will not initialise displays that do not have a monitor attached, meaning the system we are trying +to boot fails because not all the Weston display surfaces are available. + +There does not appear to be a command line option to force virtual monitors to be attached to virtual displays immediately. Looking through the +Gtk user interface code (and the other front ends) there does not appear to be a call into the qemu core that requests the connection of a virtual +monitor to the virtual displays - my guess is that qemu only connects a monitor when a render request first happens (or similar), but I have not followed the code paths deeper than the source files in ```QEMU/ui/```. + +I also tried using the ```screengrab``` command to screenshot each head, but this does not need sufficient to cause the display to be marked +enabled in the guest. + +While we could possibly automate the GUI using some external tool, we ultimately need to run this in a CI environment using +```egl-headless``` or similar. +Steps to reproduce: +1. Launch qemu with virtio-gpu-gl setting max_outputs > 1 +2. On guest, ```cat /sys/drm/class/card0-Virtual-2``` - it reads "disabled" +3. On host, switch the view to look at the second display ("virtio-gpu-gl-pci.1") +4. On guest, ```cat /sys/drm/class/card0-Virtual-2``` - it now reads "enabled" diff --git a/results/classifier/118/graphic/1111 b/results/classifier/118/graphic/1111 new file mode 100644 index 000000000..849d2dc0a --- /dev/null +++ b/results/classifier/118/graphic/1111 @@ -0,0 +1,48 @@ +graphic: 0.901 +x86: 0.878 +device: 0.845 +performance: 0.808 +debug: 0.783 +semantic: 0.744 +peripherals: 0.728 +architecture: 0.717 +PID: 0.685 +network: 0.672 +ppc: 0.665 +kernel: 0.618 +vnc: 0.525 +register: 0.520 +i386: 0.497 +files: 0.475 +hypervisor: 0.433 +socket: 0.403 +user-level: 0.387 +mistranslation: 0.372 +boot: 0.353 +permissions: 0.347 +arm: 0.332 +TCG: 0.309 +risc-v: 0.293 +VMM: 0.262 +virtual: 0.230 +KVM: 0.174 +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/118/graphic/1113 b/results/classifier/118/graphic/1113 new file mode 100644 index 000000000..ab5de8f2f --- /dev/null +++ b/results/classifier/118/graphic/1113 @@ -0,0 +1,44 @@ +graphic: 0.897 +device: 0.790 +semantic: 0.755 +vnc: 0.645 +PID: 0.624 +architecture: 0.559 +VMM: 0.527 +TCG: 0.500 +risc-v: 0.479 +mistranslation: 0.454 +ppc: 0.433 +files: 0.420 +arm: 0.385 +boot: 0.365 +socket: 0.364 +performance: 0.353 +kernel: 0.344 +virtual: 0.339 +i386: 0.329 +network: 0.324 +permissions: 0.303 +debug: 0.302 +x86: 0.292 +register: 0.260 +user-level: 0.253 +KVM: 0.251 +hypervisor: 0.163 +assembly: 0.122 +peripherals: 0.063 + +TMPDIR is not usable for snapshot-blockdevs, if not root +Description of problem: +for using static disk-content we're using `snapshot`-flag for certain disks and set `TMPDIR` to a VM-specific path. + +when started as root, all is ok. + +when started as non-root, `getenv(TMPDIR)` in function `get_tmp_filename()` in file `block.c` return `NULL`, because glibc handles `TMPDIR` as `UNSECURE_ENVVAR` (glibc-src: `sysdeps/generic/unsecvars.h`) + +well, we could compile qemu by ourself, but then we might miss important updates, so maybe this can be solved in main-source? + +possible solutions: +- additionally look at another var like `QEMU_TMPDIR`, if `getenv("TMPDIR")` results in `NULL` +- add a global option to qemu like `--tmpdir=...` +- add a device-specific option like `snapshotdir=...` diff --git a/results/classifier/118/graphic/1115 b/results/classifier/118/graphic/1115 new file mode 100644 index 000000000..4aa708a3a --- /dev/null +++ b/results/classifier/118/graphic/1115 @@ -0,0 +1,44 @@ +graphic: 0.977 +hypervisor: 0.928 +device: 0.921 +PID: 0.881 +performance: 0.839 +ppc: 0.822 +architecture: 0.814 +socket: 0.759 +VMM: 0.729 +register: 0.723 +vnc: 0.679 +boot: 0.673 +semantic: 0.607 +permissions: 0.552 +debug: 0.529 +assembly: 0.527 +risc-v: 0.526 +kernel: 0.490 +arm: 0.471 +network: 0.462 +virtual: 0.397 +peripherals: 0.364 +user-level: 0.328 +mistranslation: 0.284 +files: 0.262 +TCG: 0.220 +x86: 0.153 +i386: 0.124 +KVM: 0.065 + +qemu 7.0.0 stuck at Windows boot logo with SeaBios and MBR disk +Description of problem: +When trying to boot an MBR Windows guest with SeaBios, it is stuck at the blue Windows boot logo, before the loading circle. +Changing the vGPU doesn't help, 0% cpu load just frozen. Even if I boot a WinPE iso, the same happens. +Even after 30 minutes, the same. +Rebooted host multiple times. +Since SeaBios is the default in qemu and virt-manager I imagine many VMs are installed as MBR and thus will be stuck. +To boot the VM I have to: +- switch to UEFI (TianoCore) +- boot WinPE iso +- use proprietary software to convert the Windows disk from MBR to GPT +Then it boots just fine but I imagine not many users will be able to do this. +Steps to reproduce: +1. boot Windows image / WinPE iso with SeaBios diff --git a/results/classifier/118/graphic/1129 b/results/classifier/118/graphic/1129 new file mode 100644 index 000000000..d7ff89b89 --- /dev/null +++ b/results/classifier/118/graphic/1129 @@ -0,0 +1,53 @@ +graphic: 0.900 +performance: 0.866 +semantic: 0.855 +assembly: 0.802 +permissions: 0.791 +debug: 0.786 +architecture: 0.782 +virtual: 0.759 +arm: 0.753 +device: 0.750 +register: 0.701 +PID: 0.700 +socket: 0.692 +user-level: 0.684 +ppc: 0.680 +TCG: 0.671 +files: 0.669 +vnc: 0.656 +kernel: 0.649 +KVM: 0.623 +risc-v: 0.608 +peripherals: 0.606 +network: 0.598 +hypervisor: 0.597 +VMM: 0.593 +i386: 0.592 +boot: 0.554 +x86: 0.436 +mistranslation: 0.424 + +aarch64:qemu7.0.0 static compile error +Description of problem: +I'm trying to static compile qemu so I can chroot into different architectures and use podman for simulating amd64 containers. +However, when I tried to configure using the command above, I got the following error: + +``` +FAILED: qemu-aarch64_be +c++ -o qemu-aarch64_be libcommon.fa.p/cpus-common.c.o libcommon.fa.p/page-vary-common.c.o libcommon.fa.p/disas_arm-a64.cc.o libcommon.fa.p/disas_libvixl_vixl_a64_decoder-a64.cc.o libcommon.fa.p/disas_libvixl_vixl_a64_disasm-a64.cc.o libcommon.fa.p/disas_libvixl_vixl_a64_instructions-a64.cc.o libcommon.fa.p/disas_libvixl_vixl_compiler-intrinsics.cc.o libcommon.fa.p/disas_libvixl_vixl_utils.cc.o libcommon.fa.p/disas_arm.c.o libcommon.fa.p/hw_core_cpu-common.c.o libcommon.fa.p/hw_core_machine-smp.c.o libcommon.fa.p/accel_accel-user.c.o libcommon.fa.p/common-user_safe-syscall.S.o libcommon.fa.p/common-user_safe-syscall-error.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_aarch64_signal.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_aarch64_cpu_loop.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_cpu.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_crypto_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_debug_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_gdbstub.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_iwmmxt_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_m_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_mve_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_neon_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_op_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_tlb_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-m-nocp.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-mve.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-neon.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-vfp.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_vec_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_vfp_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_cpu_tcg.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_kvm-stub.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_cpu64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_gdbstub64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_helper-a64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_mte_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_pauth_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_sve_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-a64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-sve.c.o libqemu-aarch64_be-linux-user.fa.p/trace_control-target.c.o libqemu-aarch64_be-linux-user.fa.p/cpu.c.o libqemu-aarch64_be-linux-user.fa.p/disas.c.o libqemu-aarch64_be-linux-user.fa.p/gdbstub.c.o libqemu-aarch64_be-linux-user.fa.p/page-vary.c.o libqemu-aarch64_be-linux-user.fa.p/semihosting_arm-compat-semi.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_optimize.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_region.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-common.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-op.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-op-gvec.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-op-vec.c.o libqemu-aarch64_be-linux-user.fa.p/fpu_softfloat.c.o libqemu-aarch64_be-linux-user.fa.p/accel_accel-common.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_tcg-all.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_cpu-exec-common.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_cpu-exec.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_tcg-runtime-gvec.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_tcg-runtime.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_translate-all.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_translator.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_user-exec.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_user-exec-stub.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_elfload.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_exit.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_fd-trans.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_linuxload.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_main.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_mmap.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_signal.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_strace.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_syscall.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_thunk.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_uaccess.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_uname.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_flatload.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_semihost.c.o libqemu-aarch64_be-linux-user.fa.p/meson-generated_.._aarch64_be-linux-user-gdbstub-xml.c.o -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libhwcore.fa libqom.fa -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -static-pie -fstack-protector-strong -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -Wp,-D_GLIBCXX_ASSERTIONS -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,--start-group libqemuutil.a libhwcore.fa libqom.fa /usr/lib/libz.a -lrt -lutil -lm -pthread -lgthread-2.0 -lglib-2.0 -lpcre -lsysprof-capture-4 -lstdc++ -Wl,--end-group +/usr/bin/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../../lib/libglib-2.0.a(gutils.c.o): in function `g_get_user_database_entry': +gutils.c:(.text+0x324): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +/usr/bin/ld: gutils.c:(.text+0xf4): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +/usr/bin/ld: gutils.c:(.text+0xe0): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +/usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../../lib/libc.a(init-first.o): in function `__libc_init_first': +(.text+0x10): relocation truncated to fit: R_AARCH64_LD64_GOTPAGE_LO15 against symbol `__environ' defined in .bss section in /usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../../lib/libc.a(environ.o) +/usr/bin/ld: (.text+0x10): warning: too many GOT entries for -fpic, please recompile with -fPIC +collect2: error: ld returned 1 exit status +ninja: build stopped: subcommand failed. +make: *** [Makefile:163: run-ninja] Error 1 +``` +Same error for both mentioned kernels in different aarch64 hardwares. +Steps to reproduce: +1. Download the tarball from version 7.0.0 +2. Run the configure as mentioned on the above command diff --git a/results/classifier/118/graphic/1144 b/results/classifier/118/graphic/1144 new file mode 100644 index 000000000..83ccdb182 --- /dev/null +++ b/results/classifier/118/graphic/1144 @@ -0,0 +1,43 @@ +graphic: 0.959 +device: 0.882 +arm: 0.824 +VMM: 0.815 +architecture: 0.734 +PID: 0.633 +semantic: 0.608 +files: 0.548 +ppc: 0.544 +socket: 0.504 +mistranslation: 0.492 +user-level: 0.469 +network: 0.464 +performance: 0.455 +debug: 0.399 +vnc: 0.393 +register: 0.380 +permissions: 0.365 +TCG: 0.316 +boot: 0.290 +peripherals: 0.276 +hypervisor: 0.231 +kernel: 0.218 +risc-v: 0.193 +virtual: 0.142 +i386: 0.131 +KVM: 0.097 +assembly: 0.057 +x86: 0.043 + +Cannot install on ArcoLinux +Description of problem: +I tried to install with my package manager +``` +paru -S qemu-git +``` +and got these errors +``` +qemu-git: /usr/share/qemu/bios-microvm.bin exists in filesystem (owned by seabios) +qemu-git: /usr/share/qemu/vgabios-ati.bin exists in filesystem (owned by seabios) +``` + +I tried searching around for a solution but I can't seem to find anything relevant to my situation. diff --git a/results/classifier/118/graphic/1151 b/results/classifier/118/graphic/1151 new file mode 100644 index 000000000..f27e77218 --- /dev/null +++ b/results/classifier/118/graphic/1151 @@ -0,0 +1,79 @@ +graphic: 0.866 +performance: 0.825 +permissions: 0.807 +KVM: 0.775 +device: 0.726 +ppc: 0.685 +hypervisor: 0.658 +kernel: 0.605 +risc-v: 0.582 +PID: 0.564 +semantic: 0.552 +vnc: 0.513 +socket: 0.466 +i386: 0.447 +VMM: 0.445 +virtual: 0.439 +peripherals: 0.421 +user-level: 0.417 +network: 0.407 +boot: 0.404 +files: 0.391 +architecture: 0.384 +debug: 0.384 +TCG: 0.372 +x86: 0.362 +arm: 0.326 +register: 0.296 +mistranslation: 0.195 +assembly: 0.176 + +when guest unexpect shutdown,can't enter system,the terminal has a black screen +Description of problem: + +Steps to reproduce: +1.guest unexpect shutdown + +2.when start again,cpu usage is high and can't enter the guest system + +3.restart guest can recovery + +**libvirt print：** + +`2022-08-11 14:39:58.080+0000: 1942: warning : qemuDomainObjTaint:6079 : Domain id=117 name='GDT99d2578e-f06e-4fbe-88dd-7d9dd56fd02d' uuid=99d2578e-f06e-4fbe-88dd-7d9dd56fd02d is tainted: high-privileges + +2022-08-11 14:39:58.080+0000: 1942: warning : qemuDomainObjTaint:6079 : Domain id=117 name='GDT99d2578e-f06e-4fbe-88dd-7d9dd56fd02d' uuid=99d2578e-f06e-4fbe-88dd-7d9dd56fd02d is tainted: custom-argv + +2022-08-11 14:40:28.792+0000: 741037: warning : qemuDomainObjBeginJobInternal:946 : Cannot start job (modify, none, none) for domain GDT99d2578e-f06e-4fbe-88dd-7d9dd56fd02d; current job is (none, none, migration in) owned by (0 <null>, 0 <null>, 0 remoteDispatchDomainMigratePrepare3Params (flags=0x203)) for (0s, 0s, 30s) + +2022-08-11 14:40:28.792+0000: 741037: error : qemuDomainObjBeginJobInternal:968 : Timed out during operation: cannot acquire state change lock (held by monitor=remoteDispatchDomainMigratePrepare3Params) +` + + +**user perf to analyse:** + +\#top -d 3 -Hp 1311519 + + + +\#perf record -a -g -p 1311519 sleep 20 + +\#report -n --header --stdio + + + + +**query kvm stat:** + + \# perf stat -e 'kvm:*' -a -p 1311519 sleep 20 + + + + +kvm vmexit stat: + +\#perf kvm stat record -a -p 1311519 sleep 10 + +\#perf kvm stat report --event=vmexit + + diff --git a/results/classifier/118/graphic/1151450 b/results/classifier/118/graphic/1151450 new file mode 100644 index 000000000..e5a602c82 --- /dev/null +++ b/results/classifier/118/graphic/1151450 @@ -0,0 +1,53 @@ +mistranslation: 0.996 +graphic: 0.945 +x86: 0.944 +files: 0.900 +device: 0.886 +architecture: 0.885 +semantic: 0.871 +network: 0.672 +permissions: 0.637 +PID: 0.626 +register: 0.598 +ppc: 0.596 +virtual: 0.572 +hypervisor: 0.567 +socket: 0.535 +performance: 0.535 +boot: 0.531 +vnc: 0.512 +arm: 0.488 +user-level: 0.474 +TCG: 0.449 +debug: 0.443 +VMM: 0.403 +risc-v: 0.381 +kernel: 0.380 +i386: 0.360 +peripherals: 0.317 +assembly: 0.229 +KVM: 0.170 + +wrong description in qemu manual + + +Description: +man qemu, there is a line: +qemu-system-x86_84 --drive file=gluster://192.0.2.1/testvol/a.img +seems should be: +qemu-system-x86_64 --drive file=gluster://192.0.2.1/testvol/a.img + +Additional info: +* operating system +arch linux x86_64 +* package version(s) +1.4.0 +* config and/or log files etc. + + +Steps to reproduce: +man qemu + +This typo was fixed in commit db2d5eba652ec back in 2013, but we forgot to close the bug. Oops, and belated thanks for the report! + + diff --git a/results/classifier/118/graphic/1162 b/results/classifier/118/graphic/1162 new file mode 100644 index 000000000..3dcf7c76a --- /dev/null +++ b/results/classifier/118/graphic/1162 @@ -0,0 +1,42 @@ +graphic: 0.918 +x86: 0.917 +vnc: 0.896 +network: 0.885 +device: 0.816 +KVM: 0.712 +PID: 0.679 +peripherals: 0.667 +semantic: 0.540 +debug: 0.521 +socket: 0.455 +TCG: 0.412 +architecture: 0.384 +arm: 0.365 +files: 0.339 +risc-v: 0.323 +register: 0.301 +user-level: 0.292 +boot: 0.287 +mistranslation: 0.215 +ppc: 0.210 +VMM: 0.192 +permissions: 0.152 +kernel: 0.150 +i386: 0.142 +virtual: 0.134 +hypervisor: 0.127 +performance: 0.124 +assembly: 0.055 + +`./configure` gives `big/little test failed` error when attempting to statically link on Fedora 36 +Description of problem: +I'm having trouble attempting to build the QEMU System emulator statically linked. The error `./configure` gives `big/little test failed` with nothing else. I couldn't find any information relating to this. I'm not sure where to start fixing this. If anyone can help me with this, thanks! +Steps to reproduce: +1. `git clone https://gitlab.com/qemu-project/qemu.git` +2. `cd qemu` +3. `git submodule init` +4. `git submodule update` +5. `./configure --enable-kvm --enable-vnc --enable-vhost-net --enable-avx2 --enable-avx512f --target-list=x86_64-softmmu --static` +6. Observe build error +Additional information: + diff --git a/results/classifier/118/graphic/1162227 b/results/classifier/118/graphic/1162227 new file mode 100644 index 000000000..39e6dfb5c --- /dev/null +++ b/results/classifier/118/graphic/1162227 @@ -0,0 +1,60 @@ +graphic: 0.897 +permissions: 0.843 +semantic: 0.843 +architecture: 0.815 +assembly: 0.786 +performance: 0.773 +socket: 0.766 +peripherals: 0.763 +network: 0.753 +hypervisor: 0.737 +files: 0.736 +PID: 0.724 +register: 0.718 +user-level: 0.716 +debug: 0.713 +virtual: 0.703 +arm: 0.700 +kernel: 0.700 +KVM: 0.671 +TCG: 0.667 +ppc: 0.666 +device: 0.662 +boot: 0.651 +VMM: 0.613 +risc-v: 0.613 +vnc: 0.604 +x86: 0.598 +mistranslation: 0.589 +i386: 0.512 + +Mouse works badly when connecting to host via vnc + +Let's assume we have some physical host A. This host runs qemu guest B locally without any options like "-vnc" etc. +Then I connect from some physical host C to the host A via VNC or Teamviewer ( www.teamviewer.com ). And then I try to remote control (via this vnc connection) qemu guest. But I cannot do this because my mouse disappears when I click at my qemu guest. I see little black square only. (This square is vnc feature, it automatically appears when mouse disappears.) When I click to some objects inside guest I will instead click to another random object inside guest. + +I saw this bug in the following configurations: +* A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Windows 7 32-bit, command line: +qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow +* A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Debian squeeze 64-bit, command line: +qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -net none -drive cache=none,file=/dev/sda +* A: Debian squeeze 64-bit, x11vnc 0.9.10, Qemu 0.12.5, C: Ubuntu precise 64-bit, xvnc4viewer 4.1.1, B: Windows 7 32-bit, command line: +qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow + +Also, if I add "-usbdevice tablet" option, this bug will disappear. So, probably, this bug is not a bug. But in this case you should document it. I. e. you should add to docs something like "add -usbdevice tablet if you remote control qemu host". + +Also, if I use "-vnc" option (in the text above I didn't use it!) my mouse doesn't work as expected, too. The pointers don't line up, i. e. are not synced. But if I add "-usbdevice tablet" option, mouse will work. As far as I know this is not a bug. But then document it, too. Qemu's man page already says "It is very useful to enable the usb tablet device when using this option (option -usbdevice tablet)" in qemu 0.12.5. But I think this is not enough. The man page should say: "You should add -usbdevice tablet option and your guest OS should support tablet device or your mouse will not work". + +I tried to reproduce this bug using lastest stable version (1.4.0) and master (5e3a0f418c4d57399778cee0b55aebfb663b6425). +This versions seem to add "-usbdevice tablet" by default (and this is very good). But I think that if guest OS doesn't support tablet device then bug will still appear. So, I added option "-usbdevice mouse" to simulate this situation. And bug really appeared (i. e. mouse disappeared). So, please fix it or document it. + +Configurations: +* A: Ubuntu precise 64-bit, x11vnc 0.9.12, Qemu 1.4.0, C: Debian squeeze 64-bit, xvnc4viewer 4.1.1, B: Ubuntu precise 64-bit, command line: +/opt/qemu-1.4.0/bin/qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -drive cache=none,file=/dev/sda -net none -usbdevice mouse +* A: Ubuntu precise 64-bit, x11vnc 0.9.12, Qemu 5e3a0f418c4d57399778cee0b55aebfb663b6425, C: Debian squeeze 64-bit, xvnc4viewer 4.1.1, B: Ubuntu precise 64-bit, command line: +/opt/qemu-5e3a0f418c4d57399778cee0b55aebfb663b6425/bin/qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -drive cache=none,file=/dev/sda -net none -usbdevice mouse + +Same for -vnc option (i. e. pointers was not synced when using -usbdevice mouse) + +As you mentioned already, the solution is to use an USB tablet instead of a mouse device, and as far as I can see, it is also mentioned in the documentation of the "-vnc" parameter, so I'm closing this ticket now... + diff --git a/results/classifier/118/graphic/1163 b/results/classifier/118/graphic/1163 new file mode 100644 index 000000000..d1312e250 --- /dev/null +++ b/results/classifier/118/graphic/1163 @@ -0,0 +1,41 @@ +graphic: 0.888 +device: 0.878 +boot: 0.840 +semantic: 0.673 +performance: 0.517 +vnc: 0.489 +debug: 0.484 +mistranslation: 0.441 +architecture: 0.388 +risc-v: 0.352 +socket: 0.272 +register: 0.251 +PID: 0.227 +user-level: 0.179 +ppc: 0.097 +virtual: 0.073 +i386: 0.064 +permissions: 0.061 +VMM: 0.047 +TCG: 0.047 +x86: 0.045 +hypervisor: 0.044 +peripherals: 0.031 +arm: 0.027 +files: 0.021 +kernel: 0.015 +KVM: 0.012 +network: 0.009 +assembly: 0.007 + +qemu doesn't boot Solaris 2.2 +Description of problem: +Booting from the CDROM hangs +Steps to reproduce: +1. Run the command line above with a fresh disk image +2. The console contains: +``` +Trying cdrom:d... +(is ? +``` +3. No further progress diff --git a/results/classifier/118/graphic/1177 b/results/classifier/118/graphic/1177 new file mode 100644 index 000000000..d4839af99 --- /dev/null +++ b/results/classifier/118/graphic/1177 @@ -0,0 +1,46 @@ +graphic: 0.978 +architecture: 0.951 +kernel: 0.943 +network: 0.942 +boot: 0.923 +device: 0.921 +performance: 0.872 +user-level: 0.844 +semantic: 0.838 +ppc: 0.796 +mistranslation: 0.769 +arm: 0.723 +files: 0.704 +PID: 0.624 +permissions: 0.569 +debug: 0.522 +vnc: 0.475 +TCG: 0.440 +register: 0.367 +virtual: 0.358 +x86: 0.349 +VMM: 0.340 +risc-v: 0.277 +socket: 0.275 +peripherals: 0.255 +assembly: 0.246 +i386: 0.160 +hypervisor: 0.114 +KVM: 0.094 + +booting linux hangs with -cpu max or -cpu max,lpa2=off, but works with -cpu cortex-a57 +Description of problem: + +Steps to reproduce: +1. Snag mini.iso from http://ports.ubuntu.com/ubuntu-ports/dists/bionic-updates/main/installer-arm64/current/images/netboot/mini.iso +2. qemu-img create ubuntu-image.img 20G +3. dd if=/dev/zero of=flash1.img bs=1M count=64 +4. dd if=/dev/zero of=flash0.img bs=1M count=64 +5. dd if=/home/imp/git/qemu/00-build/pc-bios/edk2-aarch64-code.fd of=flash0.img conv=notrunc +6. Run the above command +7. Select install, watch the kernel hang. +8. Change -cpu max to -cpu cortex-a57 and it will work. -cpu max,lpa2=off also exhibits the problem +Additional information: +Just grabbed git and built it with ./configure in /home/imp/git/qemu/00-build. + +pm215 on irc suggested that it was an old EDK2 and a newer one is needed to cope with the newer CPU features in -cpu max diff --git a/results/classifier/118/graphic/1185 b/results/classifier/118/graphic/1185 new file mode 100644 index 000000000..db4d184c3 --- /dev/null +++ b/results/classifier/118/graphic/1185 @@ -0,0 +1,35 @@ +graphic: 0.973 +ppc: 0.758 +device: 0.758 +semantic: 0.655 +network: 0.558 +mistranslation: 0.545 +debug: 0.540 +socket: 0.530 +arm: 0.529 +TCG: 0.495 +vnc: 0.469 +kernel: 0.454 +files: 0.413 +PID: 0.413 +boot: 0.393 +architecture: 0.385 +VMM: 0.376 +register: 0.304 +x86: 0.279 +KVM: 0.264 +risc-v: 0.260 +i386: 0.236 +hypervisor: 0.183 +peripherals: 0.153 +performance: 0.148 +user-level: 0.127 +assembly: 0.109 +permissions: 0.091 +virtual: 0.089 + +./configure has unprefixed calls to pkg-config and clang breaking cross-compilation +Description of problem: +The configure script (as generated) includes some calls to the toolchain without including cross compiler prefixes. This can very easily break cross compilation. Here are the locations: + +# diff --git a/results/classifier/118/graphic/1187319 b/results/classifier/118/graphic/1187319 new file mode 100644 index 000000000..b507357bd --- /dev/null +++ b/results/classifier/118/graphic/1187319 @@ -0,0 +1,43 @@ +graphic: 0.817 +device: 0.814 +performance: 0.749 +semantic: 0.689 +network: 0.681 +mistranslation: 0.648 +architecture: 0.594 +arm: 0.586 +files: 0.583 +socket: 0.563 +ppc: 0.557 +permissions: 0.555 +register: 0.541 +vnc: 0.531 +risc-v: 0.531 +peripherals: 0.436 +hypervisor: 0.388 +boot: 0.382 +user-level: 0.374 +debug: 0.362 +TCG: 0.354 +VMM: 0.337 +i386: 0.330 +PID: 0.298 +x86: 0.256 +kernel: 0.235 +virtual: 0.230 +KVM: 0.179 +assembly: 0.152 + +Ctrl-Alt-- and Ctrl-Alt-+ have no effect in SDL + +The manual page mentions Ctrl-Alt-- for shrinking a window and Ctrl-Alt-+ for enlarging it. Pressing these keys do not seem to have any effect. + +I tried -/= with and without holding shift and the numpad. By the way, the numpad plus and min do not have any effect in GTK either. + +Keyboard layout: US int with AltGr dead keys +version: 1.5.0 + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1187334 b/results/classifier/118/graphic/1187334 new file mode 100644 index 000000000..a4ca993b8 --- /dev/null +++ b/results/classifier/118/graphic/1187334 @@ -0,0 +1,43 @@ +graphic: 0.943 +network: 0.889 +device: 0.878 +x86: 0.852 +ppc: 0.838 +performance: 0.684 +socket: 0.626 +vnc: 0.563 +PID: 0.543 +VMM: 0.526 +mistranslation: 0.520 +peripherals: 0.493 +semantic: 0.473 +register: 0.455 +architecture: 0.446 +i386: 0.441 +virtual: 0.385 +user-level: 0.384 +debug: 0.384 +hypervisor: 0.342 +permissions: 0.340 +files: 0.291 +kernel: 0.273 +assembly: 0.263 +risc-v: 0.250 +boot: 0.245 +arm: 0.200 +TCG: 0.154 +KVM: 0.017 + +crash on hot-unplug of vmxnet3 + +Hot-unplug of a vmxnet3 device crashes as follows: + +(qemu) device_add id=ff,driver=vmxnet3 +[vmxnet3][WR][vmxnet3_peer_has_vnet_hdr]: Peer has no virtio extension. Task offloads will be emulated. +(qemu) device_del ff +(qemu) qemu-system-x86_64: /home/pbonzini/work/upstream/qemu/net/net.c:315: qemu_del_net_client: Assertion `queues != 0' failed. + +Looks like this assertion does not trigger with the current version anymore, so I think we could close this bug. Or can you still reproduce it? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1191457 b/results/classifier/118/graphic/1191457 new file mode 100644 index 000000000..120a53804 --- /dev/null +++ b/results/classifier/118/graphic/1191457 @@ -0,0 +1,36 @@ +graphic: 0.984 +device: 0.910 +architecture: 0.907 +kernel: 0.887 +socket: 0.877 +network: 0.876 +permissions: 0.874 +VMM: 0.869 +vnc: 0.856 +ppc: 0.854 +assembly: 0.850 +register: 0.848 +KVM: 0.825 +files: 0.818 +arm: 0.811 +risc-v: 0.797 +TCG: 0.738 +PID: 0.735 +boot: 0.718 +debug: 0.682 +i386: 0.658 +performance: 0.581 +hypervisor: 0.575 +mistranslation: 0.575 +semantic: 0.572 +x86: 0.559 +peripherals: 0.501 +virtual: 0.303 +user-level: 0.288 + +broken build without sdl + +vl.c fails to build if not using sdl since no_frame variable is only defined if CONFIG_SDL, while QEMU_OPTION_no_frame tries to set it without ifdef + +the bug was fixed in a1077090cea97df26a754d16d7c9e1d410d81eaa + diff --git a/results/classifier/118/graphic/1194 b/results/classifier/118/graphic/1194 new file mode 100644 index 000000000..504095cd3 --- /dev/null +++ b/results/classifier/118/graphic/1194 @@ -0,0 +1,45 @@ +graphic: 0.979 +device: 0.966 +PID: 0.813 +files: 0.810 +network: 0.810 +register: 0.792 +debug: 0.790 +kernel: 0.788 +vnc: 0.748 +socket: 0.732 +performance: 0.731 +architecture: 0.709 +i386: 0.681 +x86: 0.669 +VMM: 0.652 +peripherals: 0.648 +virtual: 0.638 +ppc: 0.627 +semantic: 0.620 +permissions: 0.605 +user-level: 0.587 +risc-v: 0.558 +hypervisor: 0.527 +boot: 0.527 +TCG: 0.514 +KVM: 0.490 +arm: 0.483 +assembly: 0.302 +mistranslation: 0.249 + +Initialization of device virtio-net-pci failed: failed to find romfile "efi-virtio.rom" +Description of problem: +After executing the below command inside adb shell +qemu-system-aarch64 -enable-kvm -nographic \ +-kernel Image -initrd ramdisk.img -m 512 -M virt -cpu host \ + +I am getting the below error +"qemu-system-aarch64: Initialization of device virtio-net-pci failed: failed to find romfile "efi-virtio.rom"" +Steps to reproduce: +1. adb Push qemu-system-aarch64 inside system/bin +2. Run +qemu-system-aarch64 -enable-kvm -nographic \ +-kernel Image -initrd ramdisk.img -m 512 -M virt -cpu host \ +Additional information: +Kindly help me to proceed further diff --git a/results/classifier/118/graphic/1200 b/results/classifier/118/graphic/1200 new file mode 100644 index 000000000..6ac669c71 --- /dev/null +++ b/results/classifier/118/graphic/1200 @@ -0,0 +1,55 @@ +graphic: 0.921 +device: 0.828 +performance: 0.820 +virtual: 0.764 +semantic: 0.558 +hypervisor: 0.272 +mistranslation: 0.272 +ppc: 0.244 +i386: 0.227 +network: 0.220 +x86: 0.202 +VMM: 0.189 +KVM: 0.183 +architecture: 0.179 +risc-v: 0.157 +vnc: 0.144 +debug: 0.122 +arm: 0.107 +peripherals: 0.102 +user-level: 0.097 +PID: 0.090 +register: 0.080 +kernel: 0.067 +boot: 0.059 +TCG: 0.058 +assembly: 0.027 +socket: 0.026 +permissions: 0.016 +files: 0.015 + +always zero when query-dirty-rate +Description of problem: +The creation of VM works well(by virt-install), and I can enter it by 'virsh console or ssh'. + +Now, I try to use qemu's feature: calc-dirty-rate. + +But, always get '"dirty-rate":0' when 'query-dirty-rate', occasionally '"dirty-rate":2'. + +At the same time, I run 'mbw'(mbw -t0 -n 1000000 1024 -q) in vm, a memcpy-intensive benchmark. + + +I'm not sure if some configurations of QEMU/KVM are not enabled. + +looking forward to your reply! +Steps to reproduce: +``` +1. virsh qemu-monitor-command centos-huazhang '{"execute":"calc-dirty-rate", "arguments": {"calc-time": 1}}' + + {"return":{},"id":"libvirt-16"} + +2. virsh qemu-monitor-command centos-huazhang1 '{"execute":"query-dirty-rate"}' + + {"return":{"status":"measured","sample-pages":512,"dirty-rate":0,"mode":"page-sampling","start-time":607266,"calc-time":1},"id":"libvirt-17"} + +``` diff --git a/results/classifier/118/graphic/1201 b/results/classifier/118/graphic/1201 new file mode 100644 index 000000000..fb13e8b14 --- /dev/null +++ b/results/classifier/118/graphic/1201 @@ -0,0 +1,40 @@ +graphic: 0.991 +device: 0.956 +files: 0.874 +boot: 0.817 +architecture: 0.795 +semantic: 0.763 +i386: 0.722 +PID: 0.631 +register: 0.584 +permissions: 0.572 +debug: 0.559 +network: 0.556 +performance: 0.528 +vnc: 0.496 +socket: 0.434 +mistranslation: 0.417 +user-level: 0.403 +TCG: 0.388 +arm: 0.299 +VMM: 0.287 +kernel: 0.287 +ppc: 0.286 +peripherals: 0.254 +hypervisor: 0.181 +risc-v: 0.179 +assembly: 0.177 +virtual: 0.129 +x86: 0.096 +KVM: 0.018 + +Qemu with Windows 10 +Description of problem: +I see a colored screen with flashing cursor and cannot complete Windows installation. +Steps to reproduce: +1. Install `qemu-w64-setup-20220831.exe` on Windows 10 Pro for Workstations 21H2. +2. `cd C:\Program Files\qemu` +3. `qemu-img.exe create -f raw win.img 25600M` +4. `qemu-system-i386w.exe -boot c -m 4096 -hda win.img -cdrom "C:\Users\me\Downloads\Win10_21H2_English_x64.iso"` +Additional information: + diff --git a/results/classifier/118/graphic/1205 b/results/classifier/118/graphic/1205 new file mode 100644 index 000000000..279cb6043 --- /dev/null +++ b/results/classifier/118/graphic/1205 @@ -0,0 +1,37 @@ +graphic: 0.968 +architecture: 0.942 +device: 0.935 +peripherals: 0.899 +semantic: 0.822 +mistranslation: 0.783 +performance: 0.778 +network: 0.726 +debug: 0.721 +user-level: 0.603 +PID: 0.591 +boot: 0.458 +register: 0.451 +TCG: 0.413 +hypervisor: 0.360 +socket: 0.331 +files: 0.324 +vnc: 0.286 +VMM: 0.252 +assembly: 0.230 +virtual: 0.171 +permissions: 0.125 +risc-v: 0.122 +x86: 0.080 +kernel: 0.052 +i386: 0.047 +arm: 0.027 +KVM: 0.011 +ppc: 0.009 + +Cannot use `-serial stdio` on macbook pro, apple silicon +Description of problem: +When I run the command above, it will show below: +``` +(qemu) qemu-system-aarch64: -serial stdio: cannot use stdio by multiple character devices +qemu-system-aarch64: -serial stdio: could not connect serial device to character backend 'stdio' +``` diff --git a/results/classifier/118/graphic/1207 b/results/classifier/118/graphic/1207 new file mode 100644 index 000000000..8c13cfa6d --- /dev/null +++ b/results/classifier/118/graphic/1207 @@ -0,0 +1,33 @@ +graphic: 0.979 +device: 0.971 +architecture: 0.932 +semantic: 0.931 +virtual: 0.902 +performance: 0.859 +debug: 0.778 +network: 0.644 +peripherals: 0.470 +VMM: 0.466 +mistranslation: 0.465 +permissions: 0.454 +boot: 0.441 +PID: 0.389 +hypervisor: 0.376 +user-level: 0.347 +risc-v: 0.337 +register: 0.316 +assembly: 0.299 +TCG: 0.287 +files: 0.278 +ppc: 0.266 +vnc: 0.223 +kernel: 0.192 +socket: 0.151 +arm: 0.131 +i386: 0.099 +x86: 0.043 +KVM: 0.027 + +Cannot use qcow2 to create a VM on apple silicon macbook +Description of problem: +Nothing to output when I input the command above. And it seems not to boot successfully. diff --git a/results/classifier/118/graphic/1214 b/results/classifier/118/graphic/1214 new file mode 100644 index 000000000..4e591ff0e --- /dev/null +++ b/results/classifier/118/graphic/1214 @@ -0,0 +1,31 @@ +graphic: 0.991 +device: 0.799 +performance: 0.647 +peripherals: 0.338 +risc-v: 0.285 +mistranslation: 0.279 +network: 0.273 +architecture: 0.222 +hypervisor: 0.180 +arm: 0.139 +permissions: 0.127 +boot: 0.108 +VMM: 0.108 +files: 0.107 +debug: 0.075 +register: 0.072 +user-level: 0.071 +semantic: 0.068 +virtual: 0.066 +kernel: 0.052 +PID: 0.048 +assembly: 0.046 +vnc: 0.044 +ppc: 0.038 +TCG: 0.031 +socket: 0.027 +x86: 0.014 +KVM: 0.013 +i386: 0.010 + +qemu-riscv64 mmap will exhaust all physical memory diff --git a/results/classifier/118/graphic/1216 b/results/classifier/118/graphic/1216 new file mode 100644 index 000000000..228fe435c --- /dev/null +++ b/results/classifier/118/graphic/1216 @@ -0,0 +1,39 @@ +graphic: 0.955 +virtual: 0.950 +device: 0.879 +performance: 0.711 +architecture: 0.698 +VMM: 0.691 +kernel: 0.639 +PID: 0.617 +files: 0.585 +semantic: 0.580 +debug: 0.536 +boot: 0.520 +hypervisor: 0.489 +socket: 0.487 +mistranslation: 0.482 +permissions: 0.460 +register: 0.433 +network: 0.424 +arm: 0.422 +vnc: 0.408 +TCG: 0.361 +i386: 0.339 +risc-v: 0.338 +ppc: 0.310 +KVM: 0.302 +x86: 0.267 +user-level: 0.169 +peripherals: 0.162 +assembly: 0.064 + +System crashes/hangs when running qemu-img convert +Description of problem: +**Upon running the above command, the Virtual Machine simply crashes and is irrecoverable** +Steps to reproduce: +1. **Start Ubuntu 20.04 or SIFT Workstation** +2. **sudo apt-get install qemu** +3. **qemu-img convert -O raw JEA.vmdk JEA.vmdk.raw** +Additional information: +I have also run this on macOS and it just hangs and never completes diff --git a/results/classifier/118/graphic/1219 b/results/classifier/118/graphic/1219 new file mode 100644 index 000000000..4de3f292c --- /dev/null +++ b/results/classifier/118/graphic/1219 @@ -0,0 +1,43 @@ +graphic: 0.980 +device: 0.922 +KVM: 0.867 +mistranslation: 0.863 +debug: 0.803 +semantic: 0.748 +peripherals: 0.658 +network: 0.648 +files: 0.634 +architecture: 0.603 +vnc: 0.573 +PID: 0.560 +permissions: 0.557 +performance: 0.538 +hypervisor: 0.438 +register: 0.434 +TCG: 0.416 +boot: 0.397 +i386: 0.362 +socket: 0.341 +virtual: 0.340 +user-level: 0.320 +risc-v: 0.288 +ppc: 0.288 +VMM: 0.277 +kernel: 0.259 +x86: 0.258 +arm: 0.242 +assembly: 0.162 + +--enable-kvm not work for riscv64-softmmu +Description of problem: +I want to enable kvm for qemu-system-riscv64, so I compile it with `--enable-kvm` as above. But the log shows + +```sh + Targets and accelerators + KVM support : NO +``` + +And also compiled qemu-system-riscv64 does not support kvm. +Steps to reproduce: +1. clone the repo +2. `./configure --target-list=riscv64-softmmu --enable-kvm` diff --git a/results/classifier/118/graphic/1220 b/results/classifier/118/graphic/1220 new file mode 100644 index 000000000..43aa7fb9e --- /dev/null +++ b/results/classifier/118/graphic/1220 @@ -0,0 +1,46 @@ +graphic: 0.982 +device: 0.898 +network: 0.763 +performance: 0.751 +semantic: 0.688 +debug: 0.562 +PID: 0.550 +boot: 0.510 +architecture: 0.474 +VMM: 0.448 +risc-v: 0.446 +kernel: 0.416 +peripherals: 0.371 +mistranslation: 0.361 +TCG: 0.349 +user-level: 0.345 +vnc: 0.338 +socket: 0.336 +assembly: 0.332 +files: 0.314 +KVM: 0.302 +register: 0.279 +permissions: 0.270 +ppc: 0.265 +hypervisor: 0.262 +arm: 0.248 +virtual: 0.170 +i386: 0.101 +x86: 0.076 + +when migrate,I unplugged the disk, why can't I force cancel the job task use qmp +Description of problem: +when migrate,I unplugged the disk,the block job will hung,but why can't I force cancel the job task +Steps to reproduce: +1.migrate a guset to another host with non-share disk (iscsi) + +2.unplug the disk + +3.then force cancel the block job task + + +but it not work,the cancle handle is not work + + + + diff --git a/results/classifier/118/graphic/1225187 b/results/classifier/118/graphic/1225187 new file mode 100644 index 000000000..4436a1330 --- /dev/null +++ b/results/classifier/118/graphic/1225187 @@ -0,0 +1,73 @@ +graphic: 0.827 +architecture: 0.770 +performance: 0.747 +i386: 0.682 +debug: 0.667 +semantic: 0.605 +device: 0.545 +user-level: 0.509 +network: 0.503 +x86: 0.470 +peripherals: 0.446 +hypervisor: 0.400 +PID: 0.381 +socket: 0.371 +virtual: 0.352 +ppc: 0.338 +kernel: 0.305 +boot: 0.266 +vnc: 0.253 +files: 0.247 +mistranslation: 0.242 +permissions: 0.239 +arm: 0.236 +register: 0.196 +TCG: 0.161 +KVM: 0.157 +risc-v: 0.146 +VMM: 0.141 +assembly: 0.087 + +qemu hangs in windows 7 host with -serial pipe:windbg + +Execution line: +qemu-system-i386.exe -m 512 c:\Disks\Qemu_XP_en.vhd -serial pipe:windbg + +It waits for the pipe. +Execute windbg +c:\WINDDK\7600.16385.1\Debuggers\windbg.exe -k com:pipe,port=\\.\pipe\windbg,resets=0,reconnect + +GUI black screen shown. QEMU hangs. + +qemu v1.5.3 (c0b1a7e207094dba0b37a892b41fe4cab3195e44). MinGW built. + +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.] + +Tested and this issue still affects the latest version of QEMU (8.2.0) compiled for Windows. + +Instructions in original post are still sufficient to reproduce the problem on Windows 7 x64. +Both i386 and x86_64 were tested and both result in a hung QEMU process. + +The GUI does not open until after the other end of the pipe connects (to WinDbg or other). + +Using -display gtk results in a hung GUI window with a white screen. +Using -display sdl results in a responsive GUI window, but the VM is still hung after the text "SeaBIOS (version rel-...)" is printed to the screen. + +Running with "-d trace:serial_read,trace:serial_write,trace:serial_update_parameters" results in the following output to the console: +serial_update_parameters baudrate=9600 parity='N' data=5 stop=1 +serial_update_parameters baudrate=9600 parity='N' data=5 stop=1 + +I can post additional logs if provided with appropriate parameters for QEMU. + +This bug tracker for QEMU has been obsolete for years. If you think there's a problem with QEMU, please file a full report in the gitlab bugtracker: https://gitlab.com/qemu-project/qemu/-/issues . Thanks. + + +Thank you for the info. + +Current issues tracking this bug: +https://gitlab.com/qemu-project/qemu/-/issues/675 +https://gitlab.com/qemu-project/qemu/-/issues/1468 +https://gitlab.com/qemu-project/qemu/-/issues/1802 + diff --git a/results/classifier/118/graphic/1230232 b/results/classifier/118/graphic/1230232 new file mode 100644 index 000000000..f4ecf01f9 --- /dev/null +++ b/results/classifier/118/graphic/1230232 @@ -0,0 +1,67 @@ +graphic: 0.862 +device: 0.836 +ppc: 0.747 +boot: 0.741 +performance: 0.644 +hypervisor: 0.629 +architecture: 0.626 +mistranslation: 0.620 +vnc: 0.574 +semantic: 0.558 +PID: 0.509 +user-level: 0.484 +register: 0.465 +permissions: 0.421 +kernel: 0.416 +network: 0.409 +socket: 0.358 +debug: 0.344 +TCG: 0.343 +files: 0.339 +virtual: 0.332 +VMM: 0.314 +KVM: 0.300 +peripherals: 0.272 +risc-v: 0.258 +arm: 0.198 +assembly: 0.157 +x86: 0.117 +i386: 0.114 + +mac99 does not find mac os x 10.4 dvd + +Hi there, + +I've compiled qemu 1.6.0 and ripped my Mac OS X 10.4 dvd to iso format. +Now I'm trying to get qemu to boot the dvd and install the OS with: + +qemu-system-ppc64 -M mac99 -m 256 -cdrom ./tiger.iso -boot d -sdl -display sdl -net nic -net user -prom-env 'boot-args=-v' -cpu G4 -hda ./tiger.img + +It shows the grey apple logo for a few seconds and then I get the following boot prompt: +------------------------------------------------- +standard timeslicing quantum is 10000 us +vm_page_bootstrap: 60198 free pages +mig_table_max_displ = 70 +Copyright (c) 1982, 1986, 1989, 1991, 1993 + The Regents of the University of California. All rights reserved. + +using 655 buffer headers and 655 cluster IO buffer headers +ApplePlatformExpert::getGMTTimeOfDay can not provide time of day RTC did not show up +Security auditing service present +BSM auditing present +disabled +rooting via boot-uuid from /chosen: 8ABB5AFF-FC7A-310A-9BFE-8A263F654562 +Waiting on <dict ID="0"><key>IOProviderClass</key><string ID="1">IOResources</string><key>IOResource +Match</key><string ID="2">boot-uuid-media</string></dict> +Still waiting for root device +Still waiting for root device +Still waiting for root device +Still waiting for root device +Still waiting for root device +------------------------------------------------- + +It keeps repeating the "Still waiting for root device" ? + +I've set this to "Fix released" since this bug was fixed with the last set of macio rewrites which were released with QEMU 2.6, although both 2.7 and the upcoming 2.8 release include further fixes in this area. + + diff --git a/results/classifier/118/graphic/1231 b/results/classifier/118/graphic/1231 new file mode 100644 index 000000000..4a2ed84b3 --- /dev/null +++ b/results/classifier/118/graphic/1231 @@ -0,0 +1,43 @@ +graphic: 0.969 +x86: 0.968 +debug: 0.907 +device: 0.822 +hypervisor: 0.728 +vnc: 0.678 +semantic: 0.652 +performance: 0.516 +PID: 0.490 +risc-v: 0.485 +network: 0.437 +VMM: 0.434 +kernel: 0.417 +ppc: 0.416 +mistranslation: 0.415 +virtual: 0.405 +files: 0.367 +arm: 0.367 +architecture: 0.331 +KVM: 0.305 +i386: 0.302 +boot: 0.245 +TCG: 0.236 +socket: 0.193 +user-level: 0.192 +register: 0.135 +permissions: 0.055 +peripherals: 0.048 +assembly: 0.045 + +Loading migration of VM in debug state fails (with potential solution) +Description of problem: +``` +qemu-system-x86_64: invalid runstate transition: 'inmigrate' -> 'debug' +Aborted (core dumped) +``` +Steps to reproduce: +1. Start VM with gdbstub +2. Pause VM via gdbstub +3. Save migration snapshot via HMP: `migrate "exec: gzip -c > foo.gz"` +4. Start new QEMU instance from snapshot by adding these args to whatever you used to launch QEMU: `-incoming "exec: gzip -c -d foo.gz"` +Additional information: +This can be fixed by adding `{ RUN_STATE_INMIGRATE, RUN_STATE_DEBUG },` to `runstate_transitions_def` in `softmmu/runstate.c`. It's not clear if there are any negative ramifications of this, but it seems to work for me? diff --git a/results/classifier/118/graphic/1240 b/results/classifier/118/graphic/1240 new file mode 100644 index 000000000..c9cdd70f9 --- /dev/null +++ b/results/classifier/118/graphic/1240 @@ -0,0 +1,45 @@ +graphic: 0.904 +device: 0.874 +network: 0.854 +architecture: 0.806 +socket: 0.767 +ppc: 0.761 +KVM: 0.760 +vnc: 0.753 +x86: 0.751 +files: 0.738 +PID: 0.734 +VMM: 0.730 +TCG: 0.729 +kernel: 0.723 +performance: 0.720 +mistranslation: 0.714 +arm: 0.710 +register: 0.704 +i386: 0.678 +hypervisor: 0.668 +debug: 0.652 +risc-v: 0.628 +user-level: 0.623 +permissions: 0.607 +semantic: 0.598 +boot: 0.550 +peripherals: 0.535 +virtual: 0.333 +assembly: 0.325 + +The help document of qemu-nbd misses an option +Description of problem: +The "--help" option of qemu-nbd misses the option "tls-hostname". +Steps to reproduce: +1. For the option "tls-hostname", the following code appears during option parsing and modifies the tlshostname in qemu-nbd.c:760-762. + +``` + case QEMU_NBD_OPT_TLSHOSTNAME: + tlshostname = optarg; + break; +``` +Additional information: +But it does not appear in the document provided by "--help". + +It may prevent users from using the relevant function. diff --git a/results/classifier/118/graphic/1243 b/results/classifier/118/graphic/1243 new file mode 100644 index 000000000..afc358ff0 --- /dev/null +++ b/results/classifier/118/graphic/1243 @@ -0,0 +1,31 @@ +graphic: 0.835 +architecture: 0.421 +device: 0.385 +mistranslation: 0.322 +semantic: 0.270 +virtual: 0.208 +performance: 0.163 +arm: 0.143 +peripherals: 0.109 +ppc: 0.103 +boot: 0.097 +debug: 0.077 +permissions: 0.075 +VMM: 0.065 +i386: 0.064 +TCG: 0.034 +vnc: 0.034 +x86: 0.033 +register: 0.022 +user-level: 0.022 +risc-v: 0.022 +PID: 0.021 +hypervisor: 0.021 +network: 0.018 +assembly: 0.016 +KVM: 0.016 +socket: 0.007 +files: 0.005 +kernel: 0.003 + +Floating-point-exception in ide_set_sector diff --git a/results/classifier/118/graphic/1252 b/results/classifier/118/graphic/1252 new file mode 100644 index 000000000..a20f6150b --- /dev/null +++ b/results/classifier/118/graphic/1252 @@ -0,0 +1,47 @@ +graphic: 0.901 +mistranslation: 0.827 +ppc: 0.824 +device: 0.822 +PID: 0.792 +architecture: 0.788 +files: 0.780 +performance: 0.775 +socket: 0.742 +network: 0.742 +semantic: 0.723 +kernel: 0.712 +assembly: 0.673 +debug: 0.628 +virtual: 0.621 +register: 0.616 +permissions: 0.582 +peripherals: 0.551 +VMM: 0.540 +vnc: 0.539 +boot: 0.537 +risc-v: 0.533 +user-level: 0.506 +arm: 0.399 +hypervisor: 0.391 +KVM: 0.375 +x86: 0.301 +TCG: 0.286 +i386: 0.190 + +Debian Raspberry Pi images do not boot with version 7 and higher +Description of problem: +The Debian Bullseye RPi4 4GB image [here](https://raspi.debian.net/tested-images/) does not boot with versions 7 and higher, while it does boot with v6.2.0. The Bookworm image works with v7. +Steps to reproduce: +0. `export DEB_VERS=5.10.0-11` +1. `wget https://raspi.debian.net/tested/20220121_raspi_4_bullseye.img.xz` +2. `dd if=/dev/null of=disk-$DEB_VERS.img bs=1M seek=10240` + * NB: This creates a 10 GB file +3. `xzcat $RPI_IMG | dd of=disk-$DEB_VERS.img conv=notrunc status=progress` +4. `partx -a -v disk-$DEB_VERS.img` +5. `mount /dev/loop0p1 /mnt` +6. `cp /mnt/initrd.img-$DEB_VERS-arm64 .` +7. `cp /mnt/vmlinuz-$DEB_VERS-arm64 .` +8. `umount /mnt` +9. `qemu-system-aarch64 -M virt -m 4096 -cpu max -drive format=raw,file=disk-$DEB_VERS.img -nographic -append "console=tty0 console=ttyAMA0,115200 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 cma=64M rootwait" -initrd initrd.img-$DEB_VERS-arm64 -kernel vmlinuz-$DEB_VERS-arm64` +Additional information: +The URL for the image in step 1 has been known to change, so if you get a 404, go to the URL above and find the correct one. diff --git a/results/classifier/118/graphic/1256 b/results/classifier/118/graphic/1256 new file mode 100644 index 000000000..2801b9707 --- /dev/null +++ b/results/classifier/118/graphic/1256 @@ -0,0 +1,52 @@ +graphic: 0.956 +device: 0.857 +PID: 0.830 +network: 0.752 +arm: 0.744 +semantic: 0.742 +socket: 0.643 +permissions: 0.634 +debug: 0.618 +performance: 0.590 +files: 0.587 +vnc: 0.565 +ppc: 0.554 +mistranslation: 0.543 +user-level: 0.502 +TCG: 0.438 +register: 0.437 +boot: 0.434 +risc-v: 0.354 +kernel: 0.348 +architecture: 0.342 +VMM: 0.239 +peripherals: 0.233 +virtual: 0.228 +hypervisor: 0.218 +assembly: 0.122 +x86: 0.054 +KVM: 0.043 +i386: 0.021 + +Building installer fails on Windows 10 Msys2 +Description of problem: +build fails with: +``` +make[2]: Leaving directory '/c/Users/sxlga/source/repos/qemu/build' +Traceback (most recent call last): + File "C:\Users\sxlga\source\repos\qemu\scripts\nsis.py", line 89, in <module> + main() + File "C:\Users\sxlga\source\repos\qemu\scripts\nsis.py", line 34, in main + with open( +OSError: [Errno 22] Invalid argument: 'C:/Users/sxlga/AppData/Local/Temp/tmpinyvlwkoC:/msys64/qemu/system-emulations.nsh' +ninja: build stopped: subcommand failed. +make[1]: *** [Makefile:165: run-ninja] Error 1 +make[1]: Leaving directory '/c/Users/sxlga/source/repos/qemu/build' +make: *** [GNUmakefile:11: installer] Error 2 +``` +Steps to reproduce: +1. ./configure --target-list=arm-softmmu,aarch64-softmmu +2. make all +3. make installer +Additional information: +following https://wiki.qemu.org/Hosts/W32#Native_builds_with_MSYS2 to set up toolchain diff --git a/results/classifier/118/graphic/1270 b/results/classifier/118/graphic/1270 new file mode 100644 index 000000000..4b5cd15c4 --- /dev/null +++ b/results/classifier/118/graphic/1270 @@ -0,0 +1,44 @@ +graphic: 0.885 +device: 0.865 +virtual: 0.566 +performance: 0.558 +VMM: 0.523 +network: 0.425 +KVM: 0.417 +risc-v: 0.403 +i386: 0.399 +PID: 0.372 +hypervisor: 0.330 +vnc: 0.326 +arm: 0.316 +x86: 0.276 +semantic: 0.274 +mistranslation: 0.270 +boot: 0.204 +kernel: 0.183 +register: 0.173 +debug: 0.167 +peripherals: 0.154 +ppc: 0.131 +TCG: 0.125 +user-level: 0.125 +architecture: 0.101 +permissions: 0.054 +assembly: 0.037 +socket: 0.035 +files: 0.023 + +Guest freezes if memory backing using memfd/shared/ +Description of problem: +Guest VM freezes with the following memory backing is set. Required to for virtiofs, but just setting the following the guest will freeze in around 2hours, no logs or errors generate. + + <memoryBacking> + <source type='memfd'/> + <access mode='shared'/> + </memoryBacking> +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/118/graphic/1276 b/results/classifier/118/graphic/1276 new file mode 100644 index 000000000..581e05699 --- /dev/null +++ b/results/classifier/118/graphic/1276 @@ -0,0 +1,45 @@ +graphic: 0.984 +device: 0.851 +user-level: 0.618 +semantic: 0.528 +files: 0.364 +boot: 0.362 +performance: 0.288 +i386: 0.273 +vnc: 0.262 +risc-v: 0.231 +PID: 0.221 +ppc: 0.211 +socket: 0.203 +debug: 0.190 +mistranslation: 0.174 +x86: 0.146 +network: 0.135 +register: 0.122 +arm: 0.117 +architecture: 0.080 +virtual: 0.078 +kernel: 0.078 +TCG: 0.072 +permissions: 0.063 +assembly: 0.058 +VMM: 0.050 +hypervisor: 0.043 +peripherals: 0.034 +KVM: 0.030 + +[SDL] Fractional scaling is blurry +Description of problem: +The display looks blurry +Steps to reproduce: +1. Use a Wayland compositor (eg. Sway) with scale set to `1.25` +2. Launch an Ubuntu guest with the SDL display +3. Notice blurryness +Additional information: +https://github.com/libsdl-org/SDL/issues/6438 + +Blurry display https://user-images.githubusercontent.com/67585967/197484538-fde750aa-8982-4ac2-9d83-3861f6411a31.png + +Display with 1.00 scale https://user-images.githubusercontent.com/67585967/197484417-afd1d1c5-5ea1-46ce-82c5-fa8d9b2df459.png + +It was suggested in the SDL issue (https://github.com/libsdl-org/SDL/issues/6438#issuecomment-1289513402) that it's caused by the `SDL_WINDOW_ALLOW_HIGHDPI` not being set. However, after setting that flag, the display is sharp again but it's not scaled properly (boxed) https://github.com/libsdl-org/SDL/issues/6438#issuecomment-1291663284, no idea what other changes need to be made. diff --git a/results/classifier/118/graphic/1278 b/results/classifier/118/graphic/1278 new file mode 100644 index 000000000..be140f8cf --- /dev/null +++ b/results/classifier/118/graphic/1278 @@ -0,0 +1,36 @@ +graphic: 0.960 +device: 0.863 +mistranslation: 0.712 +network: 0.528 +architecture: 0.490 +debug: 0.427 +semantic: 0.405 +kernel: 0.393 +PID: 0.386 +socket: 0.332 +x86: 0.288 +vnc: 0.277 +files: 0.267 +ppc: 0.248 +TCG: 0.247 +boot: 0.246 +performance: 0.236 +user-level: 0.227 +i386: 0.225 +arm: 0.217 +KVM: 0.216 +hypervisor: 0.209 +permissions: 0.203 +virtual: 0.171 +VMM: 0.166 +risc-v: 0.127 +register: 0.092 +assembly: 0.041 +peripherals: 0.031 + +Error creating encrypted qcow2 disk using qemu-img +Description of problem: +Error creating encrypted qcow2 disk using qemu-img:No crypto library supporting PBKDF in this build: Function not implemented + +Steps to reproduce: +1.qemu-img create --object secret,id=sec0,data=123456 -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 base.qcow2 1G diff --git a/results/classifier/118/graphic/1280961 b/results/classifier/118/graphic/1280961 new file mode 100644 index 000000000..5931ad7e2 --- /dev/null +++ b/results/classifier/118/graphic/1280961 @@ -0,0 +1,46 @@ +graphic: 0.965 +KVM: 0.963 +kernel: 0.885 +x86: 0.868 +files: 0.855 +device: 0.820 +architecture: 0.771 +vnc: 0.745 +PID: 0.736 +ppc: 0.735 +debug: 0.718 +semantic: 0.717 +performance: 0.695 +virtual: 0.676 +hypervisor: 0.666 +arm: 0.659 +VMM: 0.655 +risc-v: 0.625 +TCG: 0.595 +network: 0.586 +user-level: 0.571 +register: 0.563 +boot: 0.558 +i386: 0.535 +mistranslation: 0.522 +socket: 0.517 +peripherals: 0.511 +permissions: 0.470 +assembly: 0.394 + +editing the file when mount the file system using 9pfs. it will report fsync failed. + + I have get a fsync error when I use the 9pfs on the kvm guest. it appears when I use vi editor and sysbench. I have not found the reason yet. can you tell something about it? the attache is the picture. and there is no any log which I can provide. + + My qemu version is qemu-kvm-0.13.0, and my host linux distributions is 2.6.32-431.el6.x86_64 and the guest vm is the same version which enable 9pfs and 9pnet support. I use the string of "mount -t 9p -o trans=virtio test_mount /tmp/shared/ -oversion=9p2000.L,posixacl" to get the file system. + +resovled it, this is because in the kernel 2.6.32; the 9pfs doesn't implement the fsync function. just back port the code from higher version, can resolve it. + +like this patch + +https://gitorious.org/linux-gemini/mainline/commit/7a4439c406c21b1e900ed497cec1a79d05b38c07 + + + +Closing, as this problem has been resolved according to the last comment. + diff --git a/results/classifier/118/graphic/1285 b/results/classifier/118/graphic/1285 new file mode 100644 index 000000000..d2cfaae27 --- /dev/null +++ b/results/classifier/118/graphic/1285 @@ -0,0 +1,50 @@ +graphic: 0.943 +device: 0.857 +architecture: 0.831 +PID: 0.756 +debug: 0.735 +semantic: 0.692 +vnc: 0.649 +register: 0.625 +performance: 0.608 +risc-v: 0.591 +boot: 0.570 +files: 0.567 +ppc: 0.513 +arm: 0.488 +mistranslation: 0.482 +kernel: 0.428 +socket: 0.409 +permissions: 0.402 +network: 0.349 +TCG: 0.290 +VMM: 0.286 +user-level: 0.285 +hypervisor: 0.274 +virtual: 0.253 +i386: 0.232 +x86: 0.175 +assembly: 0.175 +KVM: 0.134 +peripherals: 0.107 + +Can't use spice-app on macOS because GIO can't find handler for spice+unix scheme +Description of problem: +``` +qemu-system-aarch64: info: Launching display with URI: spice+unix:///tmp/.U96NU1/spice.sock +qemu-system-aarch64: warning: GLib-GIO: No default handler found for url scheme 'spice+unix'. +qemu-system-aarch64: warning: GLib-GIO: No default handler found for url scheme 'spice+unix'. +qemu-system-aarch64: Failed to launch spice+unix:///tmp/.U96NU1/spice.sock URI: Operation not supported +qemu-system-aarch64: You need a capable Spice client, such as virt-viewer 8.0 +``` + +``` +$ virt-viewer --version +virt-viewer version 11.0 +``` +Steps to reproduce: +1. Have virt-viewer in $PATH +2. Run command above +3. Observe error above +Additional information: + diff --git a/results/classifier/118/graphic/1288 b/results/classifier/118/graphic/1288 new file mode 100644 index 000000000..827746aad --- /dev/null +++ b/results/classifier/118/graphic/1288 @@ -0,0 +1,39 @@ +graphic: 0.881 +kernel: 0.837 +device: 0.821 +architecture: 0.722 +virtual: 0.658 +semantic: 0.560 +risc-v: 0.530 +vnc: 0.525 +peripherals: 0.497 +PID: 0.490 +files: 0.478 +register: 0.475 +ppc: 0.460 +x86: 0.412 +hypervisor: 0.406 +performance: 0.405 +i386: 0.397 +boot: 0.383 +debug: 0.374 +mistranslation: 0.359 +TCG: 0.350 +socket: 0.335 +permissions: 0.305 +VMM: 0.299 +network: 0.276 +arm: 0.249 +user-level: 0.232 +assembly: 0.091 +KVM: 0.062 + +GPU passing through guest crashes +Description of problem: +First and foremost, I don't know if this is a QEMU, KVM or GPU driver issue. +I began emailing libvirt project and they advised me to contact you, then KVM and then GPU driver developer(NVIDIA). +Host is crashing from time to time. I have guest's kernel dumps(~2GB each). +Steps to reproduce: +Unfortunately, I don't have steps to reproduce. +Additional information: +I'm aware I'm not running the latest qmeu version but I'm willing to install developer version and try to reproduce or test patch if developer requires it. diff --git a/results/classifier/118/graphic/1295 b/results/classifier/118/graphic/1295 new file mode 100644 index 000000000..04317d1a3 --- /dev/null +++ b/results/classifier/118/graphic/1295 @@ -0,0 +1,57 @@ +graphic: 0.892 +x86: 0.769 +performance: 0.662 +architecture: 0.646 +semantic: 0.606 +ppc: 0.555 +PID: 0.536 +device: 0.534 +user-level: 0.492 +permissions: 0.470 +files: 0.466 +kernel: 0.439 +register: 0.376 +debug: 0.374 +TCG: 0.342 +VMM: 0.338 +peripherals: 0.296 +vnc: 0.294 +i386: 0.286 +assembly: 0.253 +arm: 0.250 +hypervisor: 0.243 +mistranslation: 0.228 +risc-v: 0.210 +network: 0.201 +socket: 0.197 +virtual: 0.185 +KVM: 0.171 +boot: 0.150 + +configure script can fail if compiler flag `-Wunused-parameter` is enabled +Description of problem: +`configure` fails with an error message: + +``` +ERROR: SafeStack is only supported by the coroutine backend ucontext +``` +Steps to reproduce: +1. Run `./configure --cross-prefix=x86_64-w64-mingw32- --disable-werror --extra-cflags=-Wunused-parameter` +Additional information: +Last part of `config.log`: + +``` +x86_64-w64-mingw32-gcc -m64 -mcx16 -I/mingw64/include -Wunused-parameter -fno-pie -mthreads -std=gnu11 -Wall -fno-pie -no-pie -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -Werror -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -L/mingw64/lib -no-pie +config-temp/qemu-conf.c: In function ‘main’: +config-temp/qemu-conf.c:1:14: error: unused parameter ‘argc’ [-Werror=unused-parameter] + 1 | int main(int argc, char *argv[]) + | ~~~~^~~~ +config-temp/qemu-conf.c:1:26: error: unused parameter ‘argv’ [-Werror=unused-parameter] + 1 | int main(int argc, char *argv[]) + | ~~~~~~^~~~~~ +cc1: all warnings being treated as errors +``` + +The configure script fails because it tries to compile small C programs with a main function which is declared with arguments `argc` and `argv` although those arguments are unused. + +Using the same compiler flag for a native build (`./configure --disable-werror --extra-cflags=-Wunused-parameter`) shows the same errors in `config.log`, but surprisingly does not fail. diff --git a/results/classifier/118/graphic/1296 b/results/classifier/118/graphic/1296 new file mode 100644 index 000000000..e71a4d91a --- /dev/null +++ b/results/classifier/118/graphic/1296 @@ -0,0 +1,38 @@ +graphic: 0.934 +x86: 0.888 +device: 0.836 +network: 0.812 +performance: 0.750 +semantic: 0.592 +boot: 0.558 +peripherals: 0.511 +files: 0.487 +debug: 0.484 +socket: 0.457 +vnc: 0.448 +TCG: 0.405 +PID: 0.380 +mistranslation: 0.361 +kernel: 0.343 +register: 0.315 +risc-v: 0.314 +permissions: 0.300 +arm: 0.259 +hypervisor: 0.252 +architecture: 0.242 +ppc: 0.238 +VMM: 0.219 +user-level: 0.200 +i386: 0.197 +virtual: 0.129 +KVM: 0.090 +assembly: 0.022 + +qemu hangs on start with a bridged NIC +Description of problem: +qemu hangs on start with a bridged NIC. And there is no difference exists the bridge or not. At the same with a user NIC (`-nic user`) everything works flawlessly. Also I tried to add `-enable-kvm` key and had no luck. +Steps to reproduce: +1. Run qemu with the specified command line. +Additional information: +I ran the strace: `strace -s 1024 -tt -ff -y -o qemu_bridge -- qemu-system-x86_64 -nic bridge` +Here are the logs: [qemu-bridge-strace.zip](/uploads/ecf8a2ba9133279fdd6f88fda5dd9ff3/qemu-bridge-strace.zip) diff --git a/results/classifier/118/graphic/1310 b/results/classifier/118/graphic/1310 new file mode 100644 index 000000000..dd7dcde6b --- /dev/null +++ b/results/classifier/118/graphic/1310 @@ -0,0 +1,220 @@ +graphic: 0.918 +user-level: 0.917 +risc-v: 0.899 +peripherals: 0.894 +ppc: 0.877 +mistranslation: 0.875 +hypervisor: 0.861 +register: 0.857 +semantic: 0.835 +virtual: 0.830 +performance: 0.829 +permissions: 0.821 +debug: 0.809 +vnc: 0.806 +TCG: 0.792 +arm: 0.790 +device: 0.759 +architecture: 0.755 +assembly: 0.739 +KVM: 0.728 +kernel: 0.714 +x86: 0.696 +socket: 0.690 +VMM: 0.684 +network: 0.673 +boot: 0.668 +PID: 0.645 +files: 0.616 +i386: 0.554 + +qemu-nbd export img and detect block if is zero with libnbd +Description of problem: +In our project,we use qemu-nbd to export a img,and use libnbd to read/write data.if the img is preallocated,we wonder the data block if is zero,we use api nbd_block_status in libnbd to get the block status,but it shows server does not support structured replies: Operation not supported.I know our qemu is too old.so,i want to know how can i know if the block in preallocated is zero or not in nbd client. +Steps to reproduce: +1.qemu-nbd -p 8889 -f raw a.img + +2.the nbd client use libnbd,code is: +```c +#include <config.h> + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <assert.h> +#include <stdbool.h> +#include <errno.h> + +#include <libnbd.h> + +static const char *bitmap; + +struct data { + bool req_one; /* input: true if req_one was passed to request */ + int count; /* input: count of expected remaining calls */ + bool fail; /* input: true to return failure */ + bool seen_base; /* output: true if base:allocation encountered */ + bool seen_dirty; /* output: true if qemu:dirty-bitmap encountered */ +}; + +static int +cb (void *opaque, const char *metacontext, uint64_t offset, + uint32_t *entries, size_t len, int *error) +{ + struct data *data = opaque; + + /* libnbd does not actually verify that a server is fully compliant + * to the spec; the asserts marked [qemu-nbd] are thus dependent on + * the fact that qemu-nbd is compliant. Furthermore, qemu 5.2 and + * 6.0 disagree on whether base:allocation includes the hole bit for + * the zeroes at 512k (both answers are compliant); but we care more + * that the zeroes show up in the dirty bitmap + */ + assert (offset == 0); + assert (!*error || (data->fail && data->count == 1 && *error == EPROTO)); + assert (data->count-- > 0); /* [qemu-nbd] */ + + if (strcmp (metacontext, LIBNBD_CONTEXT_BASE_ALLOCATION) == 0) { + assert (!data->seen_base); /* [qemu-nbd] */ + data->seen_base = true; + if (data->req_one) + assert (len == 2); /* [qemu-nbd] */ + else + assert ((len & 1) == 0 && len > 2); /* [qemu-nbd] */ + + /* Data block offset 0 size 128k */ + assert (entries[0] == 131072); assert (entries[1] == 0); + if (!data->req_one) { + if (len == 4) { + /* hole|zero offset 128k size 896k */ + assert (entries[2] == 917504); + assert (entries[3] == (LIBNBD_STATE_HOLE| + LIBNBD_STATE_ZERO)); + } + else { + assert (len == 8); + /* hole|zero offset 128k size 384k */ + assert (entries[2] == 393216); + assert (entries[3] == (LIBNBD_STATE_HOLE| + LIBNBD_STATE_ZERO)); + /* allocated zero offset 512k size 64k */ + assert (entries[4] == 65536); + assert (entries[5] == LIBNBD_STATE_ZERO); + /* hole|zero offset 576k size 448k */ + assert (entries[6] == 458752); + assert (entries[7] == (LIBNBD_STATE_HOLE| + LIBNBD_STATE_ZERO)); + } + } + } + else if (strcmp (metacontext, bitmap) == 0) { + assert (!data->seen_dirty); /* [qemu-nbd] */ + data->seen_dirty = true; + assert (len == (data->req_one ? 2 : 10)); /* [qemu-nbd] */ + + assert (entries[0] == 65536); assert (entries[1] == 0); + if (!data->req_one) { + /* dirty block offset 64K size 64K */ + assert (entries[2] == 65536); assert (entries[3] == 1); + assert (entries[4] == 393216); assert (entries[5] == 0); + /* dirty block offset 512K size 64K */ + assert (entries[6] == 65536); assert (entries[7] == 1); + assert (entries[8] == 458752); assert (entries[9] == 0); + } + } + else { + fprintf (stderr, "unexpected context %s\n", metacontext); + exit (EXIT_FAILURE); + } + + if (data->fail) { + /* Something NBD servers can't send */ + *error = data->count == 1 ? EPROTO : ECONNREFUSED; + return -1; + } + return 0; +} + +int +main (int argc, char *argv[]) +{ + struct nbd_handle *nbd; + int64_t exportsize; + struct data data; + char c; + + if (argc < 3) { + fprintf (stderr, "%s bitmap qemu-nbd [args ...]\n", argv[0]); + exit (EXIT_FAILURE); + } + bitmap = argv[1]; + + nbd = nbd_create (); + if (nbd == NULL) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + nbd_add_meta_context (nbd, LIBNBD_CONTEXT_BASE_ALLOCATION); + nbd_add_meta_context (nbd, bitmap); + + if (nbd_connect_tcp (nbd, argv[2],argv[3]) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + exportsize = nbd_get_size (nbd); + if (exportsize == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + data = (struct data) { .count = 2, }; + if (nbd_block_status (nbd, exportsize, 0, + (nbd_extent_callback) { .callback = cb, .user_data = &data }, + 0) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + assert (data.seen_base && data.seen_dirty); + + data = (struct data) { .req_one = true, .count = 2, }; + if (nbd_block_status (nbd, exportsize, 0, + (nbd_extent_callback) { .callback = cb, .user_data = &data }, + LIBNBD_CMD_FLAG_REQ_ONE) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + assert (data.seen_base && data.seen_dirty); + + /* Trigger a failed callback, to prove connection stays up. */ + data = (struct data) { .count = 2, .fail = true, }; + if (nbd_block_status (nbd, exportsize, 0, + (nbd_extent_callback) { .callback = cb, .user_data = &data }, + 0) != -1) { + fprintf (stderr, "unexpected block status success\n"); + exit (EXIT_FAILURE); + } + assert (nbd_get_errno () == EPROTO && nbd_aio_is_ready (nbd)); + assert (data.seen_base && data.seen_dirty); + + if (nbd_pread (nbd, &c, 1, 0, 0) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + if (nbd_shutdown (nbd, 0) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + nbd_close (nbd); + + exit (EXIT_SUCCESS); +} + +``` +3. +Additional information: + diff --git a/results/classifier/118/graphic/1319 b/results/classifier/118/graphic/1319 new file mode 100644 index 000000000..723192e46 --- /dev/null +++ b/results/classifier/118/graphic/1319 @@ -0,0 +1,43 @@ +graphic: 0.954 +ppc: 0.912 +vnc: 0.784 +kernel: 0.752 +device: 0.751 +semantic: 0.698 +PID: 0.697 +files: 0.636 +register: 0.565 +arm: 0.548 +TCG: 0.513 +VMM: 0.463 +debug: 0.446 +network: 0.417 +architecture: 0.397 +socket: 0.390 +permissions: 0.359 +boot: 0.354 +risc-v: 0.351 +performance: 0.332 +mistranslation: 0.289 +i386: 0.213 +x86: 0.195 +user-level: 0.191 +virtual: 0.170 +peripherals: 0.132 +KVM: 0.122 +hypervisor: 0.120 +assembly: 0.111 + +Build warnings when building qemu with 'disable-tcg' for ppc64-softmmu target +Description of problem: +Building recent upstream qemu (HEAD 2c8311241d) for 'ppc64-softmmu' target is failing due to following build warnings: + +<snip> + ../target/ppc/cpu_init.c:7018:13: error: 'ppc_restore_state_to_opc' defined but not used [-Werror=unused-function] + 7018 | static void ppc_restore_state_to_opc(CPUState *cs, +<snip> +Steps to reproduce: +1. $ git clone --recurse-submodules https://gitlab.com/qemu-project/qemu.git +2. ./configure --target-list=ppc64-softmmu --disable-tcg && make +Additional information: +Patch for this issue has been posted and reviewed at https://lore.kernel.org/all/20221116131743.658708-1-vaibhav@linux.ibm.com/ diff --git a/results/classifier/118/graphic/1324727 b/results/classifier/118/graphic/1324727 new file mode 100644 index 000000000..b48bb7507 --- /dev/null +++ b/results/classifier/118/graphic/1324727 @@ -0,0 +1,63 @@ +graphic: 0.966 +arm: 0.908 +kernel: 0.902 +debug: 0.895 +architecture: 0.888 +device: 0.888 +semantic: 0.869 +performance: 0.859 +boot: 0.858 +PID: 0.824 +user-level: 0.813 +ppc: 0.801 +register: 0.796 +permissions: 0.779 +peripherals: 0.753 +files: 0.722 +socket: 0.706 +mistranslation: 0.656 +vnc: 0.654 +assembly: 0.587 +virtual: 0.578 +network: 0.493 +VMM: 0.489 +hypervisor: 0.469 +risc-v: 0.441 +TCG: 0.426 +i386: 0.333 +KVM: 0.166 +x86: 0.068 + +qemu-system-arm segfaults without KVM on ARM + +I'm running on Odroid-XU, Debian Jessie armhf +qemu built from today's head d7d3d6092cb7edc75dc49fb90c86dd5425ab4805 + +sudo qemu-system-arm -M vexpress-a15 -drive if=none,file=arm.img,cache=writeback,id=foo -device virtio-blk-device,drive=foo -netdev user,id=user.0 -device virtio-net-device,netdev=user.0 -nographic -append 'root=/dev/vda rw console=ttyAMA0 rootwait' -kernel /usr/src/build/arm/linux-guest/arch/arm/boot/zImage -dtb a15x2.dtb +audio: Could not init `oss' audio driver +Uncompressing Linux... done, booting the kernel. +Segmentation fault + +If I run under GDB, the linux guest instance panics or hangs -- the behaviour is variable run to run. + +If I do: +sudo qemu-system-arm --enable-kvm -M vexpress-a15 -drive if=none,file=arm.img,cache=writeback,id=foo -device virtio-blk-device,drive=foo -netdev user,id=user.0 -device virtio-net-device,netdev=user.0 -nographic -append 'root=/dev/vda rw console=ttyAMA0 rootwait' -kernel /usr/src/build/arm/linux-guest/arch/arm/boot/zImage -dtb a15x2.dtb + +then the guest boots as expected. + +I tried to get a backtrace by allowinghte SEGV to dump core, and using gdb to inspect it: +Core was generated by `qemu-system-arm -M vexpress-a15 -drive if=none,file=arm.img,cache=writeback,id='. +Program terminated with signal 11, Segmentation fault. +#0 0xb53399c0 in ?? () +(gdb) bt +#0 0xb53399c0 in ?? () +Cannot access memory at address 0x28 +#1 0x0016d87e in cpu_tb_exec ( + tb_ptr=0xc786fe90 <Address 0xc786fe90 out of bounds>, cpu=0x24450d8) + at /mnt/qemu/cpu-exec.c:67 +#2 cpu_arm_exec (env=<optimized out>) at /mnt/qemu/cpu-exec.c:642 +#3 0x00000000 in ?? () + +This is a two year old bug which doesn't have an attached repro case and I haven't seen QEMU segfault like this, so I'm going to assume we've fixed this bug. Please reopen if you still have a problem with a newer QEMU, and provide a link to the guest binary that demonstrates the crash. + + diff --git a/results/classifier/118/graphic/1328 b/results/classifier/118/graphic/1328 new file mode 100644 index 000000000..42fb0cfd4 --- /dev/null +++ b/results/classifier/118/graphic/1328 @@ -0,0 +1,39 @@ +graphic: 0.973 +virtual: 0.955 +boot: 0.926 +device: 0.912 +VMM: 0.861 +architecture: 0.796 +semantic: 0.753 +performance: 0.751 +debug: 0.583 +files: 0.566 +mistranslation: 0.547 +permissions: 0.525 +risc-v: 0.524 +register: 0.498 +PID: 0.477 +assembly: 0.464 +network: 0.388 +socket: 0.371 +hypervisor: 0.351 +kernel: 0.342 +user-level: 0.319 +vnc: 0.313 +arm: 0.312 +x86: 0.307 +peripherals: 0.280 +TCG: 0.248 +KVM: 0.163 +ppc: 0.149 +i386: 0.094 + +Cannot boot any UEFI systems after upgrade edk2-ovmf +Description of problem: +After upgrading edk2-ovmf from version 202208-1 to version 202208-3 none of my virtual machines on UEFI (windows and Arch linuw guest) have successfully started. + +I'm using Virtual Manager and virt-viewer with virsh. +Steps to reproduce: +1. Update edk2-ovmf to 202208-3 +2. Restart all running VM +3. Vm with UEFI bios cannot boot diff --git a/results/classifier/118/graphic/1329 b/results/classifier/118/graphic/1329 new file mode 100644 index 000000000..48651fe5c --- /dev/null +++ b/results/classifier/118/graphic/1329 @@ -0,0 +1,42 @@ +graphic: 0.885 +performance: 0.738 +device: 0.696 +vnc: 0.359 +boot: 0.288 +semantic: 0.283 +i386: 0.273 +kernel: 0.245 +risc-v: 0.233 +x86: 0.228 +permissions: 0.219 +debug: 0.213 +VMM: 0.199 +KVM: 0.185 +network: 0.182 +files: 0.180 +socket: 0.170 +ppc: 0.144 +hypervisor: 0.132 +mistranslation: 0.127 +arm: 0.126 +PID: 0.120 +register: 0.113 +user-level: 0.101 +peripherals: 0.098 +TCG: 0.097 +virtual: 0.042 +architecture: 0.031 +assembly: 0.028 + +Screen doesn't update until mouse pointer moves over it +Description of problem: +When changing the color scheme in CDE, the screen should change +color everywhere at once, but doesn't do so. It only updates +in the area where the mouse moves. And there it does so over +the whole width of the screen . +Steps to reproduce: +1. Change color scheme in CDE +2. Move around mouse pointer +Additional information: +Screen capture of the problem +https://youtu.be/qZJzACIxSuk diff --git a/results/classifier/118/graphic/1331859 b/results/classifier/118/graphic/1331859 new file mode 100644 index 000000000..c750b66d8 --- /dev/null +++ b/results/classifier/118/graphic/1331859 @@ -0,0 +1,51 @@ +graphic: 0.921 +kernel: 0.883 +VMM: 0.828 +architecture: 0.812 +semantic: 0.731 +arm: 0.709 +ppc: 0.688 +device: 0.663 +PID: 0.562 +vnc: 0.560 +performance: 0.556 +network: 0.535 +socket: 0.504 +risc-v: 0.490 +peripherals: 0.488 +mistranslation: 0.481 +hypervisor: 0.458 +files: 0.444 +register: 0.435 +permissions: 0.430 +user-level: 0.389 +assembly: 0.379 +TCG: 0.370 +boot: 0.368 +KVM: 0.345 +debug: 0.286 +virtual: 0.267 +i386: 0.187 +x86: 0.094 + +QEMU kernel panic on Windows with arithmetic syntax error + +During attempts to bring-up QEMU 64-bit ARM support I discovered a kernel panics that only occur on Windows but work properly on Linux. + +The issue can be reproduced by running the following command line: + +$ ./arm-softmmu/qemu-system-arm -M versatilepb -kernel $IMAGES/vmlinuz-3.2.0-4-versatile -initrd $IMAGES/initrd.img-3.2.0-4-versatile -hda $IMAGES/debian_wheezy_armel_standard.qcow2 -append "root=/dev/sda1" + +where $IMAGES is the location where the images are downloaded from http://people.debian.org/~aurel32/qemu/armel/. + +This was reproduced with both a custom built QEMU as well as the QEMU image installed by http://qemu.weilnetz.de/w32/qemu_w32-setup-20140617.exe. + +The same command line runs properly on Linux using a custom built QEMU. + +The Windows versions of QEMU do appear to work properly using the arm-test images available on qemu.org. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1333 b/results/classifier/118/graphic/1333 new file mode 100644 index 000000000..5fd132ef4 --- /dev/null +++ b/results/classifier/118/graphic/1333 @@ -0,0 +1,41 @@ +graphic: 0.960 +device: 0.759 +user-level: 0.693 +virtual: 0.631 +semantic: 0.566 +performance: 0.495 +VMM: 0.438 +mistranslation: 0.412 +arm: 0.372 +ppc: 0.322 +peripherals: 0.308 +debug: 0.265 +PID: 0.263 +TCG: 0.216 +files: 0.192 +network: 0.188 +architecture: 0.187 +hypervisor: 0.094 +vnc: 0.083 +risc-v: 0.072 +register: 0.069 +permissions: 0.063 +socket: 0.043 +boot: 0.041 +x86: 0.027 +kernel: 0.016 +i386: 0.013 +assembly: 0.009 +KVM: 0.003 + +vhost-user-test qos-test fails on s390x host +Description of problem: +The qos-test is now definitely failing in the ubuntu-20.04-s390x-all CI job. See https://gitlab.com/qemu-project/qemu/-/jobs/3363173491 , then click on "Complete Raw" to see the full log. Quoting: + +``` +ERROR:../tests/qtest/vhost-user-test.c:248:wait_for_fds: assertion failed: (s->fds_num) +** +ERROR:../tests/qtest/qos-test.c:191:subprocess_run_one_test: child process (/arm/virt/virtio-mmio/virtio-bus/vhost-user-gpio-device/vhost-user-gpio/vhost-user-gpio-tests/read-guest-mem/memfile/subprocess [274051]) failed unexpectedly + +(test program exited with status code -6) +``` diff --git a/results/classifier/118/graphic/1342686 b/results/classifier/118/graphic/1342686 new file mode 100644 index 000000000..900c74569 --- /dev/null +++ b/results/classifier/118/graphic/1342686 @@ -0,0 +1,64 @@ +graphic: 0.915 +user-level: 0.865 +device: 0.814 +boot: 0.790 +architecture: 0.761 +semantic: 0.761 +performance: 0.674 +ppc: 0.670 +kernel: 0.628 +mistranslation: 0.619 +x86: 0.603 +files: 0.598 +hypervisor: 0.589 +debug: 0.572 +permissions: 0.567 +arm: 0.562 +register: 0.556 +PID: 0.555 +assembly: 0.509 +risc-v: 0.508 +vnc: 0.497 +i386: 0.460 +network: 0.456 +peripherals: 0.443 +socket: 0.431 +virtual: 0.405 +VMM: 0.398 +TCG: 0.383 +KVM: 0.312 + +Windows 95 setup hangs + +Windows 95 (first version, not 95A or OSR2) setup hangs on QEMU version 2.0.0. It was compiled from the sources on Fedora 20. +Setup starts without problems, it goes through the first phase and then hangs on the "Getting ready to run Windows 95 for the first time..." screen (http://www.guidebookgallery.org/screenshots/win95#win95startupshutdownsplash1correctaspect). + +Steps to reproduce: +qemu-img create -f qcow2 win95.img 2G +qemu -L . -machine isapc -cpu pentium -m 32 -vga std -soundhw sb16 -hda win95.img -cdrom POLWIN95.ISO -fda BOOT95A.IMA -boot a +after this select default options everywhere. When it asks to remove the boot floppy do "eject floppy0" and confirm. +It displays the "Getting ready to run Windows 95 for the first time..." and hangs. + +The same behavior can be observed on 2.1.0-rc2. On 1.7.1 It hangs immediately after this screen, it hangs on displaying a underscore cursor. + +I managed to complete the setup on QEMU 1.6.2. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I've tried the recent QEMU 2.10 (Windows build qemu-w64-setup-20171006.exe) and the bug is still there. It hangs right after "Getting ready to run Windows 95 for the first time..." screen. + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1342704 b/results/classifier/118/graphic/1342704 new file mode 100644 index 000000000..cc258838b --- /dev/null +++ b/results/classifier/118/graphic/1342704 @@ -0,0 +1,56 @@ +graphic: 0.893 +files: 0.843 +device: 0.840 +socket: 0.789 +network: 0.770 +vnc: 0.764 +PID: 0.764 +i386: 0.716 +ppc: 0.709 +semantic: 0.697 +permissions: 0.688 +TCG: 0.687 +register: 0.681 +architecture: 0.652 +mistranslation: 0.642 +risc-v: 0.630 +performance: 0.612 +kernel: 0.611 +VMM: 0.605 +x86: 0.588 +boot: 0.587 +debug: 0.569 +arm: 0.492 +peripherals: 0.491 +hypervisor: 0.455 +KVM: 0.382 +virtual: 0.366 +user-level: 0.344 +assembly: 0.166 + +error: Crash of qemu-img/qemu-io on the qcow2 image with large values in 'incompatible features' field + +qemu-io and qemu-img fails with an assertion (see below) at attempt to interact with the qcow2 image having large values in the 'incompatible features' header field. + + util/error.c:34: error_set: Assertion `*errp == ((void *)0)' failed. + + +The backtrace file and the test image can be found in the attachment. The backtraces are for the next command: + + qemu-img check -f qcow2 test_image + + +The image was generated by the qcow2 image fuzzer. + +qemu.git head: 5a7348045091a2bc15 + + + +Fixed: + +commit 12ac6d3db721a288c8953c5c253230aa0949a0e1 +Author: Kevin Wolf <email address hidden> +Date: Thu Jul 17 11:41:53 2014 +0200 + + qcow2: Fix error path for unknown incompatible features + diff --git a/results/classifier/118/graphic/1343 b/results/classifier/118/graphic/1343 new file mode 100644 index 000000000..4bcf8cb36 --- /dev/null +++ b/results/classifier/118/graphic/1343 @@ -0,0 +1,66 @@ +architecture: 0.945 +graphic: 0.926 +device: 0.869 +kernel: 0.729 +files: 0.674 +peripherals: 0.662 +PID: 0.627 +permissions: 0.608 +ppc: 0.563 +debug: 0.531 +arm: 0.525 +performance: 0.516 +mistranslation: 0.508 +semantic: 0.505 +vnc: 0.489 +socket: 0.489 +risc-v: 0.457 +boot: 0.438 +register: 0.429 +VMM: 0.399 +user-level: 0.377 +TCG: 0.344 +network: 0.337 +hypervisor: 0.300 +assembly: 0.238 +virtual: 0.202 +x86: 0.157 +i386: 0.145 +KVM: 0.120 + +qemu-system-riscv64: It cannot initialize ramfb video adapter +Description of problem: +It looks like ramfb video adapter doesn't work in riscv64 architecture. But it works fine in aarch64 architecture. +Steps to reproduce: +1. Launch the [attached kernel](/uploads/43282fa1bd6959472af4f99646b447b9/kernel) with command: +``` +qemu-system-riscv64 -machine virt -kernel kernel -device ramfb -bios none -serial stdio +``` +2. You will get the messages in console: +``` +guest fw_cfg dma-interface enabled +setup ramfb successfull +``` +3. Video adapter will not initialize. QEMU window will continue display this message: +``` +Guest has not initialized the display (yet). +``` +Additional information: +There is a useful project for aarch64 architecture - https://github.com/luickk/qemu-ramfb-aarch64-driver. This is a Bare metal driver for ramfb adapter. It works fine. I adapted it for riscv64 architecture - https://github.com/CityAceE/qemu-ramfb-riscv64-driver. I've successfully went through all problems. Driver compiles now and launches. But unfortunately ramfb doesn't initialize. I parallel traced aarch64 and riscv64. They works equal until initialization. Aarch64 changes revolution just after qemu_cfg_write_entry call, but nothing happened after qemu_cfg_write_entry call in riscv64 emulation. I spent a lot of time trying to resolve this problem, but it looks like a problem in qemu-system-riscv64. + +**UPDATE** + +Tested with Windows builds of QEMU: + +v 6.1 - The same situation as Ubuntu build 6.2. + +v 7.1.92 - Stopped with message: +``` +c:\Program Files\qemu\qemu-system-riscv64.exe: -device ramfb: ramfb device requires fw_cfg with DMA +``` + +P.S. v 7.1.92 - qemu-system-aarch64.exe with [aarch64 kernel build](/uploads/0df1d440163913c25a1505032672e1c5/kernel) works fine. + +**UPDATE2** + +[QEMU emulator version 7.0.0 (v7.0.0-11902-g1d935f4a02-dirty)](https://qemu.weilnetz.de/w64/2022/qemu-w64-setup-20220419.exe) is the last Windows build which opens my riscv64 kernel without message about requirement of fw_cfg with DMA. Next build "QEMU emulator version 7.0.90 (v7.1.0-rc0-11915-g5f9b281b8a-dirty)" already has this issue. diff --git a/results/classifier/118/graphic/1343827 b/results/classifier/118/graphic/1343827 new file mode 100644 index 000000000..067ffafa7 --- /dev/null +++ b/results/classifier/118/graphic/1343827 @@ -0,0 +1,83 @@ +graphic: 0.838 +device: 0.699 +kernel: 0.623 +socket: 0.622 +ppc: 0.507 +performance: 0.481 +register: 0.467 +boot: 0.409 +semantic: 0.405 +PID: 0.390 +network: 0.385 +architecture: 0.311 +arm: 0.305 +user-level: 0.296 +vnc: 0.262 +risc-v: 0.257 +VMM: 0.223 +files: 0.213 +debug: 0.194 +mistranslation: 0.186 +permissions: 0.177 +TCG: 0.159 +assembly: 0.136 +x86: 0.121 +i386: 0.118 +peripherals: 0.112 +virtual: 0.099 +hypervisor: 0.085 +KVM: 0.064 + +block.c: multiwrite_merge() truncates overlapping requests + +If the list of requests passed to multiwrite_merge() contains two requests where the first is for a range of sectors that is a strict subset of the second's, the second request is truncated to end where the first starts, so the second half of the second request is lost. + +This is easy to reproduce by running fio against a virtio-blk device running on qemu 2.1.0-rc1 with the below fio script. At least with fio 2.0.13, the randwrite pass will issue overlapping bios to the block driver, which the kernel is happy to pass along to qemu: + +[global] +randrepeat=0 +ioengine=libaio +iodepth=64 +direct=1 +size=1M +numjobs=1 +verify_fatal=1 +verify_dump=1 + +filename=$dev + +[seqwrite] +blocksize_range=4k-1M +rw=write +verify=crc32c-intel + +[randwrite] +stonewall +blocksize_range=4k-1M +rw=randwrite +verify=meta + +Here is a naive fix for the problem that simply avoids merging problematic requests. I guess a better solution would be to redo qemu_iovec_concat() to do the right thing. + +diff -ur old/qemu-2.1.0-rc2/block.c qemu-2.1.0-rc2/block.c +--- old/qemu-2.1.0-rc2/block.c 2014-07-15 14:49:14.000000000 -0700 ++++ qemu-2.1.0-rc2/block.c 2014-07-17 23:03:14.224169741 -0700 +@@ -4460,7 +4460,9 @@ + int64_t oldreq_last = reqs[outidx].sector + reqs[outidx].nb_sectors; + + // Handle exactly sequential writes and overlapping writes. +- if (reqs[i].sector <= oldreq_last) { ++ // If this request ends before the previous one, don't merge. ++ if (reqs[i].sector <= oldreq_last && ++ reqs[i].sector + reqs[i].nb_sectors >= oldreq_last) { + merge = 1; + } + +Thanks for reporting this bug. I'm writing a test case and fix, will CC you on the patches. + +Please keep in mind that no ordering is guaranteed between requests that are in-flight at the same time. Therefore it is unusual to submit overlapping requests and could indicate a bug in the application. + +Triaging old bug tickets... has Stefan's fix be included? Could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1349 b/results/classifier/118/graphic/1349 new file mode 100644 index 000000000..a4ffd1d14 --- /dev/null +++ b/results/classifier/118/graphic/1349 @@ -0,0 +1,37 @@ +graphic: 0.800 +device: 0.754 +arm: 0.558 +socket: 0.487 +debug: 0.469 +risc-v: 0.400 +vnc: 0.374 +boot: 0.324 +kernel: 0.315 +PID: 0.287 +VMM: 0.274 +register: 0.264 +semantic: 0.245 +files: 0.241 +network: 0.233 +x86: 0.222 +ppc: 0.200 +i386: 0.197 +KVM: 0.190 +TCG: 0.178 +mistranslation: 0.139 +performance: 0.127 +architecture: 0.122 +user-level: 0.101 +permissions: 0.079 +virtual: 0.078 +hypervisor: 0.071 +peripherals: 0.052 +assembly: 0.046 + +Windows Installer Error +Description of problem: +Windows Installer Barfs +Steps to reproduce: +1. Either run exe installer or do ```scoop update -g "qemu" ``` +Additional information: + diff --git a/results/classifier/118/graphic/1355644 b/results/classifier/118/graphic/1355644 new file mode 100644 index 000000000..88b19478e --- /dev/null +++ b/results/classifier/118/graphic/1355644 @@ -0,0 +1,52 @@ +graphic: 0.805 +x86: 0.735 +device: 0.544 +semantic: 0.465 +performance: 0.381 +ppc: 0.360 +architecture: 0.319 +boot: 0.296 +user-level: 0.292 +permissions: 0.268 +network: 0.246 +socket: 0.235 +register: 0.234 +debug: 0.229 +PID: 0.212 +vnc: 0.196 +risc-v: 0.185 +files: 0.180 +mistranslation: 0.179 +peripherals: 0.174 +arm: 0.162 +kernel: 0.156 +VMM: 0.127 +hypervisor: 0.123 +virtual: 0.121 +TCG: 0.093 +i386: 0.075 +assembly: 0.038 +KVM: 0.036 + +windows7 reboot bluesreen 0x0000005c + +I have met sevaral blue screen with 0x0000005c(0x0000010b,0x00000003,0x00000000,0x00000000) after windows7 reboot. +It always happens just before the windows iron animation appears. + +my qemu version is qemu-2.1.0 +my guest os is windows7 32bits sp1 + +my qemu commandline is +./x86_64-softmmu/qemu-system-x86_64 -m 2048 -hda system.inst -spice port=5940,disable-ticketing -monitor stdio --enable-kvm + +This bug doesn't happen always，and i don‘t know how to reproduce it. + +But i have a special way to produce such a bluescreen. +I set nmi dump on and set windows to collect dump file and set auto reboot after system fail on. +Then i send a nmi to guest, and then after collecting dump file , windows will auto reboot and then such a blue screen happens. +And this can be reproduced always. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1355697 b/results/classifier/118/graphic/1355697 new file mode 100644 index 000000000..2f14ffc08 --- /dev/null +++ b/results/classifier/118/graphic/1355697 @@ -0,0 +1,81 @@ +graphic: 0.863 +semantic: 0.766 +performance: 0.762 +user-level: 0.735 +device: 0.734 +architecture: 0.719 +PID: 0.714 +permissions: 0.692 +kernel: 0.670 +hypervisor: 0.666 +VMM: 0.644 +socket: 0.642 +vnc: 0.638 +ppc: 0.632 +KVM: 0.627 +TCG: 0.623 +register: 0.619 +network: 0.619 +files: 0.617 +x86: 0.601 +peripherals: 0.567 +i386: 0.564 +boot: 0.552 +risc-v: 0.548 +assembly: 0.523 +arm: 0.502 +mistranslation: 0.480 +virtual: 0.475 +debug: 0.472 + +qemu-img: Segfault on a fuzzed image with large values of L1/L2 entries + +'qemu-img check -r all/leaks' failed with a segmentation fault on the fuzzed image with L1/L2 entry values having UINT64 border values. + +Sequence: + 1. Unpack the attached archive, make a copy of test.img + 2. Put copy.img and backing_img.raw in the same directory + 3. Execute + +qemu-img check -f qcow2 -r all copy.img + +Result: qemu-img was killed by SIGSEGV. + +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 +Warning: cluster offset=0xfffffffffe0000 is after the end of the image file, can't properly check refcounts. +Warning: cluster offset=0x100000000000000 is after the end of the image file, can't properly check refcounts. +ERROR l2_offset=fffffffffffe00: Table is not cluster aligned; L1 entry corrupted +Repairing cluster 0 refcount=0 reference=1 +Repairing cluster 1 refcount=0 reference=1 +qcow2: Marking image as corrupt: Preventing invalid write on metadata (overlaps with refcount table); further corruption events will be suppressed +Repairing cluster 21 refcount=0 reference=1 + +4 errors were found on the image. +Data may be corrupted, or further writes to the image may corrupt it. + +2 internal errors have occurred during the check. +Image end offset: 2883584 + +I'm still working towards the repair function actually doing its job. + +Thank you for your report, + +Max + +Hi, + +Okay, so this image has the same “issue” (it's intentionally broken, so it's not really an issue) as the one in bug 1355738: There are corrupted L2 entries which are impossible for qemu to repair. Therefore, we could only ask the user to use qemu-img convert and that's all we can do. Therefore, I'm marking this fixed as well. + +Max + diff --git a/results/classifier/118/graphic/1356 b/results/classifier/118/graphic/1356 new file mode 100644 index 000000000..380fbc192 --- /dev/null +++ b/results/classifier/118/graphic/1356 @@ -0,0 +1,47 @@ +graphic: 0.954 +device: 0.808 +x86: 0.733 +mistranslation: 0.729 +debug: 0.661 +architecture: 0.643 +KVM: 0.629 +network: 0.605 +performance: 0.522 +vnc: 0.478 +semantic: 0.453 +i386: 0.450 +ppc: 0.439 +hypervisor: 0.359 +PID: 0.342 +kernel: 0.332 +boot: 0.331 +socket: 0.325 +peripherals: 0.319 +register: 0.285 +arm: 0.196 +files: 0.180 +permissions: 0.151 +virtual: 0.144 +user-level: 0.144 +assembly: 0.131 +VMM: 0.129 +TCG: 0.105 +risc-v: 0.067 + +"-set device" doesn't work with device specified in json +Description of problem: +The above QEMU command line results in: +``` +qemu-system-x86_64: -set device.ua-igd.x-igd-gms=1: there is no device "ua-igd" defined +``` +While the following command works: +``` +qemu-system-x86_64 -accel kvm -m 8192 -nodefaults -display none -net none -device vfio-pci,host=0000:00:02.0,id=ua-igd -set device.ua-igd.x-igd-gms=1 +``` +libvirt has moved to the json device specification, therefore I can no longer associate use a <qemu:commandline> section to set driver options for a specific device with this broken id association. +Steps to reproduce: +1. Create a device with an ID and use -set device.$ID to set a driver option for the device +2. Note failure when using json device format vs legacy device specification +3. Profit +Additional information: + diff --git a/results/classifier/118/graphic/1356969 b/results/classifier/118/graphic/1356969 new file mode 100644 index 000000000..27cfffa6b --- /dev/null +++ b/results/classifier/118/graphic/1356969 @@ -0,0 +1,54 @@ +graphic: 0.900 +performance: 0.896 +semantic: 0.580 +device: 0.576 +network: 0.528 +ppc: 0.522 +vnc: 0.490 +mistranslation: 0.468 +i386: 0.461 +architecture: 0.446 +socket: 0.438 +risc-v: 0.438 +user-level: 0.423 +boot: 0.417 +VMM: 0.414 +PID: 0.408 +files: 0.381 +TCG: 0.379 +x86: 0.366 +kernel: 0.345 +register: 0.305 +arm: 0.300 +virtual: 0.297 +KVM: 0.291 +peripherals: 0.279 +permissions: 0.278 +hypervisor: 0.264 +debug: 0.247 +assembly: 0.110 + +qemu-io: the 'map' command hangs on the fuzzed image + +Sequence: + 1. Unpack the attached archive, make a copy of test.img + 2. Put copy.img and backing_img.vdi in the same directory + 3. Execute + +qemu-io copy.img -c map + +Result: qemu-io processes part of the image and then hangs loading 100% of CPU time. + + +qemu.git HEAD 2d591ce2aeebf + + + +Hi, + +well, the issue for this specific image is fixed because it is detected to be corrupt before the mapping can reach the point in question (unaligned L2 table entry). However, commit 4b25bbc4c22cf39350b75bd250d568a4d975f7c5 should have fixed the problem this bug report is really about. Thus, should be fixed. + +Thanks for reporting, + +Max + diff --git a/results/classifier/118/graphic/1357445 b/results/classifier/118/graphic/1357445 new file mode 100644 index 000000000..196971647 --- /dev/null +++ b/results/classifier/118/graphic/1357445 @@ -0,0 +1,60 @@ +graphic: 0.805 +performance: 0.760 +semantic: 0.707 +files: 0.679 +device: 0.675 +user-level: 0.664 +ppc: 0.650 +socket: 0.597 +network: 0.575 +TCG: 0.571 +PID: 0.568 +kernel: 0.557 +vnc: 0.531 +VMM: 0.529 +architecture: 0.499 +arm: 0.493 +risc-v: 0.488 +hypervisor: 0.478 +permissions: 0.465 +i386: 0.439 +peripherals: 0.367 +x86: 0.363 +KVM: 0.354 +register: 0.334 +mistranslation: 0.332 +debug: 0.322 +virtual: 0.312 +boot: 0.280 +assembly: 0.257 + +qemu-img: 'amend -o compat=0.10' command failed with segfault on the fuzzed image + +qemu-img amend -o compat=0.10' failed with a segmentation fault on the fuzzed image. + +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 amend -o compat=0.10 -f qcow2 copy.img + +Result: qemu-img was killed by SIGSEGV. + +Traces can be found in the attached archive. + +qemu.git HEAD 2d591ce2aeebf + + + +Hi, + +being on 2d591ce2aeebf, I rather receive "qemu-img: Error while amending options: File too large". Judging from the traces, though, this issue (the segfault at least) should be fixed by my "[PATCH v3 0/7] block/qcow2: Improve zero cluster expansion" series anyway (when merged eventually). + +Max + +Hi, + +Well, I still (on 2.2.0-rc2) receive "File too large", so I guess that's the fix. + +Max + diff --git a/results/classifier/118/graphic/1359930 b/results/classifier/118/graphic/1359930 new file mode 100644 index 000000000..f88483a56 --- /dev/null +++ b/results/classifier/118/graphic/1359930 @@ -0,0 +1,169 @@ +graphic: 0.843 +VMM: 0.835 +user-level: 0.834 +PID: 0.823 +virtual: 0.816 +debug: 0.814 +kernel: 0.814 +boot: 0.811 +peripherals: 0.810 +hypervisor: 0.808 +device: 0.807 +architecture: 0.806 +semantic: 0.805 +network: 0.803 +register: 0.801 +arm: 0.786 +permissions: 0.772 +risc-v: 0.758 +vnc: 0.754 +performance: 0.750 +mistranslation: 0.749 +ppc: 0.734 +KVM: 0.726 +socket: 0.711 +TCG: 0.702 +assembly: 0.701 +x86: 0.673 +files: 0.612 +i386: 0.463 + +[ARMv5] Integrator/CP regression when reading FPSID register + +There seems to be a regression in QEMU 2.1.0 which demonstrates itself +when running the attached HelenOS Integrator/CP (i.e. ARMv5) image. The +offending instruction seems to be: + + vmrs r0, fpsid + +Upon its execution, HelenOS kernel receives an Undefined instruction +exception (which it does not anticipate at that point) and crashes. + +QEMU 2.0.0 was not affected by this issue. + +Command line to reproduce with QEMU 2.1.0: + +$ qemu-system-arm -M integratorcp -kernel image.boot -s -S & +$ /usr/local/cross/arm32/bin/arm-linux-gnueabi-gdb +... +(gdb) target remote localhost:1234 +Remote debugging using localhost:1234 +warning: Can not parse XML target description; XML support was disabled at compile time +0x00000000 in ?? () +(gdb) symbol-file kernel/kernel.raw +Reading symbols from /home/jermar/software/HelenOS.mainline/kernel/kernel.raw...done. +(gdb) break ras_check +Breakpoint 1 at 0x80a021bc: file arch/arm32/src/ras.c, line 67. +(gdb) c +Continuing. + +Breakpoint 1, ras_check (n=1, istate=0x813e7f70) at arch/arm32/src/ras.c:67 +67 { +(gdb) set radix 16 +Input and output radices now set to decimal 16, hex 10, octal 20. +(gdb) print istate->pc +$1 = 0x80a02458 +(gdb) disassemble 0x80a02458 +Dump of assembler code for function fpsid_read: + 0x80a02454 <+0>: vmrs r0, fpsid <======= UNDEFINED EXCEPTION INSTRUCTION + 0x80a02458 <+4>: mov pc, lr +End of assembler dump. + + +The Undefined instruction exception is not expected at this point when executing the VMRS r0,fpsid instruction. + + + +Here is the respective HelenOS kernel with debug symbols. + +Hi Jakub, + +Thanks for the test case. I've just done a git bisect using your test image above and it seems as if the offending commit is this: + + +commit 2c7ffc414d8591018248b5487757e45f7bb6bd3c +Author: Peter Maydell <email address hidden> +Date: Tue Apr 15 19:18:40 2014 +0100 + + target-arm: Fix VFP enables for AArch32 EL0 under AArch64 EL1 + + The current A32/T32 decoder bases its "is VFP/Neon enabled?" check + on the FPSCR.EN bit. This is correct if EL1 is AArch32, but for + an AArch64 EL1 the logic is different: it must act as if FPSCR.EN + is always set. Instead, trapping must happen according to CPACR + bits for cp10/cp11; these cover all of FP/Neon, including the + FPSCR/FPSID/MVFR register accesses which FPSCR.EN does not affect. + Add support for CPACR checks (which are also required for ARMv7, + but were unimplemented because Linux happens not to use them) + and make sure they generate exceptions with the correct syndrome. + + We actually return incorrect syndrome information for cases + where FP is disabled but the specific instruction bit pattern + is unallocated: strictly these should be the Uncategorized + exception, not a "SIMD disabled" exception. This should be + mostly harmless, and the structure of the A32/T32 VFP/Neon + decoder makes it painful to put the 'FP disabled?' checks in + the right places. + + Signed-off-by: Peter Maydell <email address hidden> + Reviewed-by: Peter Crosthwaite <email address hidden> + + +(Diff is viewable at http://git.qemu.org/?p=qemu.git;a=commitdiff;h=2c7ffc414d8591018248b5487757e45f7bb6bd3c) + + +HTH, + +Mark. + + +On 22 August 2014 12:17, Mark Cave-Ayland <email address hidden> wrote: +> Hi Jakub, +> +> Thanks for the test case. I've just done a git bisect using your test +> image above and it seems as if the offending commit is this: +> +> +> commit 2c7ffc414d8591018248b5487757e45f7bb6bd3c +> Author: Peter Maydell <email address hidden> +> Date: Tue Apr 15 19:18:40 2014 +0100 +> +> target-arm: Fix VFP enables for AArch32 EL0 under AArch64 EL1 +> +> The current A32/T32 decoder bases its "is VFP/Neon enabled?" check +> on the FPSCR.EN bit. This is correct if EL1 is AArch32, but for +> an AArch64 EL1 the logic is different: it must act as if FPSCR.EN +> is always set. Instead, trapping must happen according to CPACR +> bits for cp10/cp11; these cover all of FP/Neon, including the +> FPSCR/FPSID/MVFR register accesses which FPSCR.EN does not affect. +> Add support for CPACR checks (which are also required for ARMv7, +> but were unimplemented because Linux happens not to use them) +> and make sure they generate exceptions with the correct syndrome. + +Thanks for the bisect; this was actually my primary suspect +for the offending commit but I hadn't got round to looking at it. +We're trapping based on the CPACR (c1_coproc) bits being zero, +but that register only appears in ARMv6 and later, so we +accidentally disabled VFP in ARMv5 CPUs. + +Probably the best fix is to mak cpu_get_tb_cpu_state() do + + if (arm_feature(env, ARM_FEATURE_V6)) { + fpen = extract32(env->cp15.c1_coproc, 20, 2); + } else { + /* CPACR doesn't exist before v6 so VFP always accessible */ + fpen = 3; + } + +-- PMM + + +Patch which implements my suggestion of comment #4 and seems to fix this regression: +http://patchwork.ozlabs.org/patch/382215/ + + +Yes, the patch fixes the problem for me. Thank you. + +Patch had been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ed1f13d607e2c64c66bea49d + diff --git a/results/classifier/118/graphic/1360 b/results/classifier/118/graphic/1360 new file mode 100644 index 000000000..0ba0ec50a --- /dev/null +++ b/results/classifier/118/graphic/1360 @@ -0,0 +1,49 @@ +graphic: 0.934 +x86: 0.859 +semantic: 0.818 +device: 0.795 +debug: 0.639 +PID: 0.635 +architecture: 0.573 +network: 0.541 +kernel: 0.540 +permissions: 0.513 +files: 0.507 +ppc: 0.466 +boot: 0.455 +performance: 0.442 +socket: 0.439 +mistranslation: 0.406 +user-level: 0.404 +i386: 0.352 +register: 0.347 +vnc: 0.343 +risc-v: 0.237 +TCG: 0.233 +virtual: 0.230 +VMM: 0.206 +peripherals: 0.174 +arm: 0.170 +hypervisor: 0.118 +assembly: 0.109 +KVM: 0.069 + +Starting using WSL fails even if the same image is valid when starting qemu directly from windows +Description of problem: +I'm trying to follow a rust tutorial on writing a custom OS in rust. https://os.phil-opp.com/minimal-rust-kernel/ +The problem occurse when trying to run qemu from wsl. If I run qemu from a windows command line everything works as expected. +If I run the os calling qemu (installed on windows) from wsl it fails with + +``` +ERROR:../../../block.c:1715:bdrv_open_driver: assertion failed: (is_power_of_2(bs->bl.request_alignment)) +Bail out! ERROR:../../../block.c:1715:bdrv_open_driver: assertion failed: (is_power_of_2(bs->bl.request_alignment)) +``` + +I also found an old bug report that seemed to be the same issue in the old issue tracker: https://bugs.launchpad.net/qemu/+bug/1893807 +Steps to reproduce: +1. Sample code can be found at `https://github.com/phil-opp/blog_os` branch: `post-02` +2. create wsl environment +3. run `cargo install bootimage` only required on the once to install bootimage +4. run `cargo build` +5. run `cargo bootimage` to create the image +6. `qemu-system-x86_64 -drive format=raw,file=target/x86_64-blog_os/debug/bootimage-blog-os.bin` diff --git a/results/classifier/118/graphic/1361618 b/results/classifier/118/graphic/1361618 new file mode 100644 index 000000000..7d8b6d997 --- /dev/null +++ b/results/classifier/118/graphic/1361618 @@ -0,0 +1,63 @@ +graphic: 0.852 +performance: 0.792 +virtual: 0.761 +peripherals: 0.728 +user-level: 0.714 +architecture: 0.702 +vnc: 0.702 +device: 0.665 +mistranslation: 0.660 +ppc: 0.645 +semantic: 0.631 +hypervisor: 0.600 +kernel: 0.559 +VMM: 0.503 +network: 0.489 +register: 0.484 +PID: 0.474 +x86: 0.464 +socket: 0.461 +risc-v: 0.450 +arm: 0.415 +files: 0.403 +permissions: 0.398 +boot: 0.384 +TCG: 0.380 +KVM: 0.368 +debug: 0.360 +assembly: 0.347 +i386: 0.304 + +sparc cg3 1152x900 display abnormal + +when I use -vga cg3 -g 1152x900 with qemu-system-sparc, the display is abnormal +I had try qemu-2.1.0 on win2003 with openBIOS or OBP + qemu-system-sparc.exe -vga cg3 -g 1152x900 +or + qemu-system-sparc.exe -vga cg3 -g 1152x900 -bios ss5.bin + +I also try qemu-2.0.2 on debian 6.0.1a i686 on VirtualBox host win2003 +with same command, in vnc view, the display is same as on win2003. + +If I don't use -g 1152x900 parameter, everything is OK, sunOS 4.1.4 work well. + + + +Due to the OpenBIOS ROM being larger than OBP, it is currently unable to allocate enough memory for the larger 1152x900 framebuffer (and sadly it's not a simple fix to shrink down the memory requirements). + +Fortunately if you are using the real Sun ROM ss5.bin then you can just use a real Sun cgthree ROM in order to get a 1152x900 framebuffer in QEMU. Currently you can find a copy at http://people.csail.mit.edu/fredette/tme/sun-u1-nbsd.html if you don't have one handy. + +Simply rename the existing OpenBIOS QEMU,cgthree.bin ROM to QEMU,cgthree.bin.old, download the real Sun cgthree ROM and rename it to QEMU,cgthree.bin in place of the old file. Now you should find you can start QEMU with -g 1152x900 and the larger display size will work fine. + +I would say that this isn't necessarily a bug as it's more a restriction in the way OpenBIOS works, however I agree that the documentation is probably not particularly clear in this respect. One final note: the Sun cgthree ROM is fixed at 1152x900 resolution, so if you need to switch back to 1024x768 (or want to auto boot without manual intervention) then you'll need to temporarily rename the ROM files so the original OpenBIOS QEMU,cgthree.bin file is used once again. + + +Kind regards, + +Mark. + + +new QEMU,cgthree.bin work fine, thank you! + +Setting this to "invalid" since it's apparently rather a firmware than a QEMU issue. + diff --git a/results/classifier/118/graphic/1368 b/results/classifier/118/graphic/1368 new file mode 100644 index 000000000..421c11ffc --- /dev/null +++ b/results/classifier/118/graphic/1368 @@ -0,0 +1,68 @@ +graphic: 0.963 +mistranslation: 0.952 +performance: 0.929 +device: 0.914 +debug: 0.913 +ppc: 0.909 +architecture: 0.820 +x86: 0.788 +vnc: 0.782 +hypervisor: 0.779 +semantic: 0.777 +assembly: 0.774 +boot: 0.755 +i386: 0.742 +KVM: 0.741 +kernel: 0.711 +risc-v: 0.694 +VMM: 0.678 +TCG: 0.664 +PID: 0.661 +user-level: 0.624 +network: 0.578 +socket: 0.537 +arm: 0.533 +peripherals: 0.506 +permissions: 0.503 +files: 0.439 +virtual: 0.389 +register: 0.335 + +unexpect rax value +Description of problem: +- When I execute "mov -0x8(%rbp), %rax" and "movq 0xb8000, (%rax)", the value of rax should be 0x7fedf but it is 0x7fefe. It is 1 less. +Steps to reproduce: +- 1. Code currently executed +<pre> +(gdb) x/2i $pc +=> 0x2202 <vga_init+12>: mov -0x8(%rbp),%rax + 0x2206 <vga_init+16>: movq $0xb8000,(%rax) +</pre> +- 2. Value of memory address -0x8(%rbp) +<pre> +(gdb) x /xg $rbp-0x8 +0x7fec8: 0x000000000007fedf +</pre> +- 3. Value of rax before execution +<pre> +(gdb) p /x $rax +$1 = 0xfffffffd +</pre> +- 4. Value of rax after execution +<pre> +(gdb) p /x $rax +$1 = 0x7fedf +</pre> +It's all right so far. +- 5. View the current execution code again +<pre> +(gdb) x/i $pc +=> 0x2207 <vga_init+17>: movl $0xb8000,(%rax) +</pre> +the code address changed from 0x2206 to 0x2207 and the code changed from "movq xx, xx" to "movl xx, xx".<br> +Now rax is 0x7fedf. +- 6. After execution<br> +After executing "movl $0xb8000,(%rax)"<br> +The rax change to 0x7fede +Additional information: + diff --git a/results/classifier/118/graphic/1368178 b/results/classifier/118/graphic/1368178 new file mode 100644 index 000000000..bc4021258 --- /dev/null +++ b/results/classifier/118/graphic/1368178 @@ -0,0 +1,99 @@ +graphic: 0.908 +peripherals: 0.881 +register: 0.861 +permissions: 0.857 +debug: 0.847 +assembly: 0.837 +architecture: 0.801 +user-level: 0.769 +mistranslation: 0.763 +device: 0.756 +PID: 0.753 +network: 0.689 +boot: 0.682 +risc-v: 0.679 +kernel: 0.670 +VMM: 0.660 +files: 0.650 +socket: 0.647 +hypervisor: 0.634 +ppc: 0.625 +performance: 0.624 +TCG: 0.617 +semantic: 0.603 +arm: 0.596 +virtual: 0.580 +vnc: 0.550 +KVM: 0.507 +i386: 0.462 +x86: 0.462 + +Windows ME falsely detects qemu's videocards as Number Nine Imagine 128 + +A fresh installation of Windows Millennium Edition (Windows ME, WinME) as guest OS on qemu interprets qemu's videocards as Number Nine Imagine 128 with the consequence, that + +1. It is impossible to change color depth. +2. WinME uses the i128.drv Driver that is shipped with WinMe. +3. Forcing WinME to use other drivers has no effect. + + +It also doesn't matter what option for -vga was given to QEMU at command line. +cirrus, std, vmware, qxl etc. all have no effect, the videocard detected by Windows Me stays at Number Nine Imagine 128. + +Even selecting another driver in WinME and forcing WinME to use drivers such as the Cirrus Logic 5446 PCI driver has no effect. + +I also want to mention, that the BIOS isn't detected by WinME properly. +The device manager of WinME shows errors with the Plug & Play BIOS driver BIOS.vxd. + + +That is the QEMU Version: + +# qemu-system-i386 --version +QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.3), Copyright (c) 2003-2008 Fabrice Bellard + +And this was the complete command line, that was given: +# sudo /usr/bin/qemu-system-i386 -hda WinME_QEMU.img -cdrom drivers.iso -boot c -no-acpi -no-hpet -soundhw sb16 -net nic -cpu pentium3 -m 256 -vga cirrus + + + +Here's a picture of the allowed color depth. +As long as the videocard isn't detected properly, using another driver won't help and without another driver the color depth stays at 16 colors. + + +Here's a screenshot of the driver problem, that WinME shows up. +It says error "code 23", whatever that means. + + +In console mode, info pci gives the following information (see attachted screenshot) + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I am still using Kubuntu 16.04.3 LTS and that is shipped with QEMU 2.5.0 + +# qemu-system-i386 --version +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16) + +I am not planning to go into the hassle to install QEMU latest on 16.04.3 LTS. + +Could you delay the closing of the ticket until Kubuntu 18.04 LTS is released? +Then i could test it with the QEMU version that will be shipped with Kubuntu 18.04 LTS. + +As an alternative, i could also do the test with QEMU 2.5 instead. + + +Addition to my last comment. + +Ubuntu 17.10 is now shipped with QEMU 2.10. Thus we can expect that 18.04 LTS will be shipped with QEMU 2.10 or later, too. + + + +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/108 + + +Oliver, did you ever check this with a newer version of QEMU? + diff --git a/results/classifier/118/graphic/1374905 b/results/classifier/118/graphic/1374905 new file mode 100644 index 000000000..614de6f3e --- /dev/null +++ b/results/classifier/118/graphic/1374905 @@ -0,0 +1,66 @@ +graphic: 0.840 +device: 0.599 +semantic: 0.571 +architecture: 0.560 +boot: 0.557 +x86: 0.551 +mistranslation: 0.488 +user-level: 0.478 +performance: 0.461 +permissions: 0.400 +register: 0.352 +PID: 0.346 +peripherals: 0.317 +socket: 0.313 +debug: 0.286 +files: 0.285 +risc-v: 0.273 +ppc: 0.266 +network: 0.259 +vnc: 0.259 +hypervisor: 0.246 +assembly: 0.217 +i386: 0.214 +virtual: 0.156 +VMM: 0.134 +kernel: 0.130 +TCG: 0.127 +arm: 0.086 +KVM: 0.054 + +Pixelation issue in 16-bit color VGA graphics + +What happened: +I ran the 9front installation ISO (here: http://r-36.net/9front/9front-3853.02ebd469f43a.iso.bz2) in QEMU, with a blank qcow2, using `qemu-system-i386 -hda 9front.qcow2.img -cdrom 9front-3853.02ebd469f43a.iso -boot d -vga std -m 1G`. During the console boot, I accept the default display settings (1024x768x16, VESA, PS2 mouse), and 9front proceeds to the GUI boot. However, every pixel is blurred, making text illegible and the GUI unusable. + +What I expected: +Normal pixel rendering / normal display. + +Step by step instructions: +0. Install QEMU 2.1.2 (I use Homebrew's bottle, `brew install qemu`) +1. Download 9front ISO (9front-3853.02ebd469f43a.iso.bz2) +2. Create new QEMU image: `qemu-img create -f qcow2 9front.qcow2.img 20G`. +3. Boot 9front ISO: `qemu-system-i386 -hda 9front.qcow2.img -cdrom 9front-3853.02ebd469f43a.iso -boot d -vga std -m 1G` +4. It displays a console boot screen; accept default args (local, glenda, 1024x768x16, vesa, ps2, etc...) +5. GUI is drawn. +6. Pixel are blurred and unreadable + +Details: +This bug does not occur when 32 bit color is used, using the 1024x768x32. This bug does not occur when QEMU is built with SDL (in Homebrew, `brew install qemu --with-sdl`), although the console portion of 9front's boot runs significantly slower. + +System: +OS X 10.9.5 x86-64 +Macbook Retina Late 2012 +Intel i7 Ivy Bridge dual core. + +Build: +Homebrew's QEMU 2.1.2 bottle, which is build without GTK, SDL, or VDE. + + + +Is there a version that does work? If so, could you try bisecting things? + +Did you ever bisect this issue? Does it still occur with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1378 b/results/classifier/118/graphic/1378 new file mode 100644 index 000000000..c4e14b240 --- /dev/null +++ b/results/classifier/118/graphic/1378 @@ -0,0 +1,50 @@ +graphic: 0.821 +virtual: 0.736 +performance: 0.664 +kernel: 0.623 +semantic: 0.618 +device: 0.615 +KVM: 0.571 +architecture: 0.519 +PID: 0.456 +vnc: 0.425 +risc-v: 0.359 +ppc: 0.352 +VMM: 0.342 +network: 0.338 +permissions: 0.334 +socket: 0.330 +peripherals: 0.313 +boot: 0.286 +register: 0.277 +hypervisor: 0.240 +i386: 0.231 +files: 0.211 +x86: 0.198 +debug: 0.193 +arm: 0.187 +user-level: 0.158 +TCG: 0.154 +mistranslation: 0.107 +assembly: 0.035 + +iSCSI causes memory corruption +Description of problem: +This is a compound problem, which most likely involves a combination of how TrueNAS SCALE handles iSCSI triggering a problem **and** some memory-handling issue in QEMU leading to a crash. In short any Linux machine started with iSCSI handled by QEMU directly leads to a hard crash within 30s-1h. I was able to find a pattern in logs: + +1. First, a message like `QEMU[53139]: kvm: iSCSI Busy/TaskSetFull/TimeOut (retry #1 in 0 ms): TASK_SET_FULL` is logged + - it is always `TASK_SET_FULL` + - it is always `retry #1 in ... ms`, where only number of miliseconds varies + - the line is repeated multiple times, sometimes 5x and sometimes >200x +2. It is followed by a single line with one of the following: + - `double free or corruption (out)` + - `double free or corruption (!prev)` + - `kvm: ../block/block-backend.c:1567: blk_aio_write_entry: Assertion `!qiov || qiov->size == acb->bytes' failed.` + - `kvm: malloc.c:2379: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.` + - `kvm: iSCSI CheckCondition: SENSE KEY:UNIT_ATTENTION(6) ASCQ:BUS_RESET(0x2900)` + - `malloc(): invalid size (unsorted)` +3. The virtual machine crashes +Steps to reproduce: +I don't have a specific concrete steps, only clues really. This problem started happening after TrueNAS SCALE updated their iSCSI code in Bluefin release to a new upstream version. That iSCSI server still works when iSCSI is mounted by the kernel and QEMU uses a normal `/dev` entry. While there's probably some problem with it, QEMU shouldn't probably crash with memory errors. +Additional information: +While I'm a software developer, I don't code in C on a daily basis. However, looking at the errors, I have a suspicion the problem may be somewhere in the `iscsi_co_generic_cb()`, as it seems the struct is getting damaged (out of bound write?) and causes explosion somewhere down the line. diff --git a/results/classifier/118/graphic/1378554 b/results/classifier/118/graphic/1378554 new file mode 100644 index 000000000..94ec76116 --- /dev/null +++ b/results/classifier/118/graphic/1378554 @@ -0,0 +1,218 @@ +graphic: 0.890 +ppc: 0.883 +register: 0.854 +KVM: 0.835 +performance: 0.834 +TCG: 0.828 +VMM: 0.824 +hypervisor: 0.817 +mistranslation: 0.815 +debug: 0.808 +vnc: 0.806 +semantic: 0.805 +assembly: 0.802 +arm: 0.799 +permissions: 0.790 +device: 0.790 +user-level: 0.787 +peripherals: 0.783 +boot: 0.780 +network: 0.775 +files: 0.773 +risc-v: 0.769 +architecture: 0.759 +PID: 0.749 +kernel: 0.742 +virtual: 0.734 +socket: 0.712 +x86: 0.636 +i386: 0.565 + +qemu segfault in virtio_scsi_handle_cmd_req_submit on ARM 32 bit + +/home/rjones/d/qemu/arm-softmmu/qemu-system-arm \ + -global virtio-blk-device.scsi=off \ + -nodefconfig \ + -enable-fips \ + -nodefaults \ + -display none \ + -M virt \ + -machine accel=kvm:tcg \ + -m 500 \ + -no-reboot \ + -rtc driftfix=slew \ + -global kvm-pit.lost_tick_policy=discard \ + -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1001/appliance.d/kernel \ + -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1001/appliance.d/initrd \ + -device virtio-scsi-device,id=scsi \ + -drive file=/home/rjones/d/libguestfs/tmp/libguestfseV4fT5/scratch.1,cache=unsafe,format=raw,id=hd0,if=none \ + -device scsi-hd,drive=hd0 \ + -drive file=/home/rjones/d/libguestfs/tmp/.guestfs-1001/appliance.d/root,snapshot=on,id=appliance,cache=unsafe,if=none \ + -device scsi-hd,drive=appliance \ + -device virtio-serial-device \ + -serial stdio \ + -chardev socket,path=/home/rjones/d/libguestfs/tmp/libguestfseV4fT5/guestfsd.sock,id=channel0 \ + -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ + -append 'panic=1 mem=500M console=ttyAMA0 udevtimeout=6000 no_timer_check lpj=4464640 acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color' + +The appliance boots, but segfaults as soon as the virtio-scsi driver is loaded: + +supermin: internal insmod virtio_scsi.ko +[ 3.992963] scsi0 : Virtio SCSI HBA +libguestfs: error: appliance closed the connection unexpectedly, see earlier error messages + +I captured a core dump: + +Core was generated by `/home/rjones/d/qemu/arm-softmmu/qemu-system-arm -global virtio-blk-device.scsi='. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x000856bc in virtio_scsi_handle_cmd_req_submit (s=<optimized out>, + req=0x6c03acf8) at /home/rjones/d/qemu/hw/scsi/virtio-scsi.c:551 +551 bdrv_io_unplug(req->sreq->dev->conf.bs); +(gdb) bt +#0 0x000856bc in virtio_scsi_handle_cmd_req_submit (s=<optimized out>, + req=0x6c03acf8) at /home/rjones/d/qemu/hw/scsi/virtio-scsi.c:551 +#1 0x0008573a in virtio_scsi_handle_cmd (vdev=0xac4d68, vq=0xafe4b8) + at /home/rjones/d/qemu/hw/scsi/virtio-scsi.c:573 +#2 0x0004fdbe in access_with_adjusted_size (addr=80, + value=value@entry=0x4443e6c0, size=size@entry=4, access_size_min=1, + access_size_max=<optimized out>, access_size_max@entry=0, + access=access@entry=0x4fee9 <memory_region_write_accessor>, + mr=mr@entry=0xa53fa8) at /home/rjones/d/qemu/memory.c:480 +#3 0x00054234 in memory_region_dispatch_write (size=4, data=2, + addr=<optimized out>, mr=0xa53fa8) at /home/rjones/d/qemu/memory.c:1117 +#4 io_mem_write (mr=0xa53fa8, addr=<optimized out>, val=val@entry=2, + size=size@entry=4) at /home/rjones/d/qemu/memory.c:1958 +#5 0x00021c88 in address_space_rw (as=0x3b96b4 <address_space_memory>, + addr=167788112, buf=buf@entry=0x4443e790 "\002", len=len@entry=4, + is_write=is_write@entry=true) at /home/rjones/d/qemu/exec.c:2135 +#6 0x00021de6 in address_space_write (len=4, buf=0x4443e790 "\002", + addr=<optimized out>, as=<optimized out>) + at /home/rjones/d/qemu/exec.c:2202 +#7 subpage_write (opaque=<optimized out>, addr=<optimized out>, value=2, + len=4) at /home/rjones/d/qemu/exec.c:1811 +#8 0x0004fdbe in access_with_adjusted_size (addr=592, + value=value@entry=0x4443e820, size=size@entry=4, access_size_min=1, + access_size_max=<optimized out>, access_size_max@entry=0, + access=access@entry=0x4fee9 <memory_region_write_accessor>, + mr=mr@entry=0xaed980) at /home/rjones/d/qemu/memory.c:480 +#9 0x00054234 in memory_region_dispatch_write (size=4, data=2, + addr=<optimized out>, mr=0xaed980) at /home/rjones/d/qemu/memory.c:1117 +#10 io_mem_write (mr=0xaed980, addr=<optimized out>, val=2, size=size@entry=4) + at /home/rjones/d/qemu/memory.c:1958 +#11 0x00057f24 in io_writel (retaddr=1121296542, Cannot access memory at address 0x0 +addr=<optimized out>, val=2, + physaddr=592, env=0x9d6c50) at /home/rjones/d/qemu/softmmu_template.h:381 +#12 helper_le_stl_mmu (env=0x9d6c50, addr=<optimized out>, val=2, + mmu_idx=<optimized out>, retaddr=1121296542) + at /home/rjones/d/qemu/softmmu_template.h:419 +#13 0x42d5a0a0 in ?? () +Cannot access memory at address 0x0 +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) print req +$1 = (VirtIOSCSIReq *) 0x6c03acf8 +(gdb) print req->sreq +$2 = (SCSIRequest *) 0xc2c2c2c2 +(gdb) print req->sreq->dev +Cannot access memory at address 0xc2c2c2c6 +(gdb) print *req +$3 = { + dev = 0x6c000040, + vq = 0x6c000040, + qsgl = { + sg = 0x0, + nsg = 0, + nalloc = -1027423550, + size = 3267543746, + dev = 0xc2c2c2c2, + as = 0xc2c2c2c2 + }, + resp_iov = { + iov = 0xc2c2c2c2, + niov = -1027423550, + nalloc = -1027423550, + size = 3267543746 + }, + elem = { + index = 3267543746, + out_num = 3267543746, + in_num = 3267543746, + in_addr = {14033993530586874562 <repeats 1024 times>}, + out_addr = {14033993530586874562 <repeats 1024 times>}, + in_sg = {{ + iov_base = 0xc2c2c2c2, + iov_len = 3267543746 + } <repeats 1024 times>}, + out_sg = {{ + iov_base = 0xc2c2c2c2, + iov_len = 3267543746 + } <repeats 1024 times>} + }, + vring = 0xc2c2c2c2, + { + next = { + tqe_next = 0xc2c2c2c2, + tqe_prev = 0xc2c2c2c2 + }, + remaining = -1027423550 + }, + sreq = 0xc2c2c2c2, + resp_size = 3267543746, + mode = (SCSI_XFER_TO_DEV | unknown: 3267543744), + resp = { + cmd = { + sense_len = 3267543746, + resid = 3267543746, + status_qualifier = 49858, + status = 194 '\302', + response = 194 '\302' + }, + tmf = { + response = 194 '\302' + }, + an = { + event_actual = 3267543746, + response = 194 '\302' + }, + event = { + event = 3267543746, + lun = "\302\302\302\302\302\302\302", <incomplete sequence \302>, + reason = 3267543746 + } + }, + req = { + { + cmd = { + lun = "\302\302\302\302\302\302\302", <incomplete sequence \302>, + tag = 14033993530586874562, + task_attr = 194 '\302', + prio = 194 '\302', + crn = 194 '\302' + }, + cdb = 0x6c042d73 '\302' <repeats 36 times>, <incomplete sequence \302> + }, + tmf = { + type = 3267543746, + subtype = 3267543746, + lun = "\302\302\302\302\302\302\302", <incomplete sequence \302>, + tag = 14033993530586874562 + }, + an = { + type = 3267543746, + lun = "\302\302\302\302\302\302\302", <incomplete sequence \302>, + event_requested = 3267543746 + } + } +} + +This is qemu from git today (2014-10-07). + +The hardware is 32 bit ARM (ODROID-XU Samsung Exynos 5410). It is running Ubuntu 14.04 LTS as the main operating system, but I am NOT using qemu from Ubuntu (which is ancient). + +Richard, is this 3 year old bug still an issue? + + +Ah, my mail client found the thread that tells me this was fixed in commit 35e4e96c4d5bfcf. So we can close this. + + +Yes, qemu's working fine on aarch64 so this must have been fixed. + diff --git a/results/classifier/118/graphic/1379688 b/results/classifier/118/graphic/1379688 new file mode 100644 index 000000000..3fc035d2f --- /dev/null +++ b/results/classifier/118/graphic/1379688 @@ -0,0 +1,55 @@ +graphic: 0.869 +performance: 0.759 +peripherals: 0.699 +device: 0.600 +mistranslation: 0.582 +socket: 0.456 +network: 0.452 +semantic: 0.446 +hypervisor: 0.436 +user-level: 0.424 +kernel: 0.401 +permissions: 0.381 +architecture: 0.372 +vnc: 0.354 +PID: 0.353 +boot: 0.353 +ppc: 0.335 +register: 0.324 +risc-v: 0.298 +files: 0.298 +arm: 0.278 +virtual: 0.277 +x86: 0.268 +debug: 0.256 +i386: 0.237 +VMM: 0.234 +KVM: 0.225 +assembly: 0.164 +TCG: 0.159 + +qemu's monitor and parallel create huge window + +I have qemu 2.1. When I try to switch to monitor or parallel0, I get window which is 30 *thousand* pixels in height. It is only gray with no content. This did not happen with previous versions of qemu. + +Kwin crashes because it cannot handle such a huge window. + +1.6.0 is good at least. + +2.1 is OK with vte 2.90, not with 2.91 + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +On 02/08/2018, 08:32 PM, Thomas Huth wrote: +> Triaging old bug tickets... can you still reproduce this issue with the +> latest version of QEMU? Or could we close this ticket nowadays? + +The issue is long gone, feel free to close. + + +-- +js + + +Thanks for your answer! Closing now. + diff --git a/results/classifier/118/graphic/1380 b/results/classifier/118/graphic/1380 new file mode 100644 index 000000000..a1d9fb1c8 --- /dev/null +++ b/results/classifier/118/graphic/1380 @@ -0,0 +1,34 @@ +graphic: 0.984 +architecture: 0.850 +network: 0.778 +arm: 0.767 +performance: 0.730 +device: 0.717 +socket: 0.698 +risc-v: 0.590 +mistranslation: 0.571 +semantic: 0.539 +VMM: 0.537 +files: 0.505 +ppc: 0.492 +PID: 0.486 +permissions: 0.466 +register: 0.455 +debug: 0.422 +assembly: 0.391 +boot: 0.366 +vnc: 0.346 +peripherals: 0.273 +TCG: 0.271 +i386: 0.235 +kernel: 0.213 +virtual: 0.182 +user-level: 0.163 +hypervisor: 0.041 +KVM: 0.019 +x86: 0.008 + +vdagent is not working properly after live migration +Additional information: +when validating on windows server 2016 Datacenter Evaluation, i found that if vdagent process or vdservice is restarted, copy/paste from host to guest or reverse will work again. i am wondering if we should send something(eg, a event?) to guest to let it reopen the port after live migration? + diff --git a/results/classifier/118/graphic/1386197 b/results/classifier/118/graphic/1386197 new file mode 100644 index 000000000..8d893c233 --- /dev/null +++ b/results/classifier/118/graphic/1386197 @@ -0,0 +1,50 @@ +graphic: 0.860 +virtual: 0.750 +semantic: 0.634 +performance: 0.564 +user-level: 0.534 +device: 0.531 +architecture: 0.516 +vnc: 0.513 +x86: 0.511 +debug: 0.486 +hypervisor: 0.437 +ppc: 0.411 +peripherals: 0.401 +KVM: 0.372 +mistranslation: 0.368 +VMM: 0.345 +i386: 0.314 +network: 0.294 +permissions: 0.266 +PID: 0.259 +kernel: 0.257 +TCG: 0.253 +register: 0.238 +files: 0.236 +boot: 0.231 +socket: 0.204 +assembly: 0.196 +risc-v: 0.189 +arm: 0.170 + +keyboard suddenly stops working in VM and problem persists until host reboot. All super-standard setup no funny stuff + +QEMU emulator version 2.1.2, Copyright (c) 2003-2008 Fabrice Bellard +Linux HOST 3.16.3-1-ck #1 SMP PREEMPT Sun Sep 21 11:27:46 CEST 2014 x86_64 GNU/Linux + +qemu-system-x86_64 -daemonize -enable-kvm -cpu host -smp 4,maxcpus=4,sockets=1,cores=2,threads=1 -m 4096 -monitor telnet:127.0.0.1:4446,server,nowait -vga qxl -spice port=5556,ipv4,addr=127.0.0.1,disable-ticketing -soundhw all -net tap,script=no,ifname=vm6,vlan=0,vnet_hdr=on -net nic,macaddr=52:54:00:2A:F1:16,vlan=0,model=virtio -drive file=/mnt/2/VM/vm-centos.qcow2,cache=writeback,index=0,media=disk,if=virtio,aio=native -boot c -vnc :6 + + +I already had this with ubanto VM so I installed a centos one but then I type HDD password in VNC suddenly keyboard stops working forever. Kill qemu, stop qemu, start again ... same issue. Very strange. Problem in VNC, problem in vga std problem in spicec problem with options problem without options, SDL no SDL and nothing helps. dmesg only shows unhandled wrmsr like always .. so irrelevant. + +Must be problem with new kernel or nvidia driver mystery magic I suppose? But I had riced CK kernel before and no issue. Hardware didn't change. Nothing works, what is this? Can do sendkey 1 1 in console no issue. So why is all keyboard input dead in mid-operation? You see after reboot I open VM and no matter what VNC or spicec or SDL I input keyboard all normal then this! BAM all keyboard input gone! So in ubuntu I still had mouse so I used onscreen keyboard to enable SSH and then I didn't care. But now I have harddrive password, what can I do? Install different QEMU but I suppose problem with new kernel xorg stuff rather ... Can't change that! Help much appreciated. + +So installed qemu-git 2.2.r35796.gff0d487-1 from AUR shows up as QEMU emulator version 2.1.50, Copyright (c) 2003-2008 Fabrice Bellard no host system reboot but still exact same ... no wait! + +Now I see this: I can press all the printable character keys except 0-9 A-Z :space: and KP_keys so basically just -=[]\;',./` . Cheated myself into grub edit mode with sendkey now I test it and yes it is like that no shift no ESC no insert, delete, etc just those keys. What is this?! I am not sure but I think the bug was always like this I just didn't bother about the -=[]\;',./` keys. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1395958 b/results/classifier/118/graphic/1395958 new file mode 100644 index 000000000..cdd05fa5f --- /dev/null +++ b/results/classifier/118/graphic/1395958 @@ -0,0 +1,80 @@ +arm: 0.958 +graphic: 0.923 +ppc: 0.850 +device: 0.825 +performance: 0.774 +debug: 0.773 +PID: 0.734 +semantic: 0.633 +architecture: 0.577 +network: 0.523 +register: 0.517 +risc-v: 0.481 +mistranslation: 0.466 +kernel: 0.465 +TCG: 0.461 +peripherals: 0.452 +vnc: 0.449 +VMM: 0.448 +socket: 0.436 +boot: 0.435 +user-level: 0.384 +files: 0.378 +hypervisor: 0.362 +permissions: 0.334 +i386: 0.239 +x86: 0.236 +assembly: 0.208 +virtual: 0.201 +KVM: 0.092 + +boost managed_shared_memory segment on arm emulator crashes + +The following code segment crashes when run: + +#include <boost/interprocess/managed_shared_memory.hpp> +#include <boost/interprocess/allocators/allocator.hpp> +#include <boost/interprocess/containers/map.hpp> +#include <boost/interprocess/containers/vector.hpp> +#include <boost/interprocess/containers/string.hpp> + +using namespace boost::interprocess; + +int main(int argc, char** argv) +{ + namespace bi = boost::interprocess; + const char* name = "foobar"; + bi::shared_memory_object::remove(name); + bi::managed_shared_memory segment(bi::create_only, name, 10 * 1024); +} + +using qemu-arm-static +qemu-arm version 1.5.0 (Debian 1.5.0-2013.06+git74+20130802+ef1b0ae-3linaroprecise1), Copyright (c) 2003-2008 Fabrice Bellard + + +Any idea? + + uname -a +Linux ratin-dev 2.6.32 #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 armv7l armv7l armv7l GNU/Linux + + + +remote GDB (via local host ) +QEMU: Terminated via GDBstub +root@ratin-dev:/usr/local/bin# qemu-arm-static -g 1234 /usr/local/bin/test +terminate called after throwing an instance of 'boost::interprocess::interprocess_exception' + what(): Function not implemented + + +(gdb) +14 bi::managed_shared_memory segment(bi::create_only, name, 10 * 1024); +(gdb) + +Program received signal SIGABRT, Aborted. +0xf661d706 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 +(gdb) quit + + +This test case works OK for me with current QEMU head-of-git, so I think we've fixed this bug (it was probably a missing-syscall, guessing from the "function not implemented" text in the exception.) + + diff --git a/results/classifier/118/graphic/1396 b/results/classifier/118/graphic/1396 new file mode 100644 index 000000000..f2843bd8c --- /dev/null +++ b/results/classifier/118/graphic/1396 @@ -0,0 +1,33 @@ +graphic: 0.968 +device: 0.964 +semantic: 0.954 +assembly: 0.946 +mistranslation: 0.935 +architecture: 0.915 +hypervisor: 0.912 +performance: 0.873 +debug: 0.866 +virtual: 0.844 +PID: 0.812 +register: 0.759 +vnc: 0.740 +arm: 0.733 +user-level: 0.695 +socket: 0.691 +ppc: 0.679 +risc-v: 0.660 +boot: 0.645 +VMM: 0.609 +TCG: 0.513 +permissions: 0.504 +network: 0.490 +peripherals: 0.433 +i386: 0.384 +files: 0.379 +kernel: 0.267 +KVM: 0.202 +x86: 0.071 + +Is it possible to emulate QEMU 64 Bit on Windows? +Description of problem: +Is it possible to emulate 64 Bit OS on Windows QEMU version? I'm trying to emulate ESXi image but the ESXi says it can only start 32 bit VM's. When I try to start a 64 bit VM from the ESXi I get the error `Task failed on server: Module 'CPUID' power on failed. `. diff --git a/results/classifier/118/graphic/1401 b/results/classifier/118/graphic/1401 new file mode 100644 index 000000000..5b6c5e7e6 --- /dev/null +++ b/results/classifier/118/graphic/1401 @@ -0,0 +1,50 @@ +graphic: 0.931 +device: 0.786 +mistranslation: 0.726 +ppc: 0.661 +kernel: 0.629 +debug: 0.573 +network: 0.553 +semantic: 0.533 +PID: 0.509 +vnc: 0.468 +x86: 0.416 +i386: 0.412 +socket: 0.410 +user-level: 0.388 +boot: 0.383 +arm: 0.368 +hypervisor: 0.359 +performance: 0.335 +VMM: 0.327 +architecture: 0.311 +peripherals: 0.309 +TCG: 0.302 +KVM: 0.301 +files: 0.300 +risc-v: 0.286 +register: 0.248 +assembly: 0.135 +permissions: 0.112 +virtual: 0.099 + +configure uses break outside loop +Description of problem: +When running `configure` in version 7.2.0, the following message is printed multiple times: + +``` +qemu/configure: line 1885: break: only meaningful in a `for', `while', or `until' loop +``` +Steps to reproduce: +Running `configure` should be enough. My complete configure command is: + +``` +/bin/bash ./configure \ + --prefix=$PREFIX/qemu --sysconfdir=/etc$PREFIX/qemu \ + --includedir=$PREFIX/qemu/include --bindir=$PREFIX/qemu/bin \ + --sbindir=$PREFIX/qemu/sbin --libdir=$PREFIX/qemu/lib/amd64 \ + --libexecdir=$PREFIX/qemu/libexec/amd64 \ + --localstatedir=/var$PREFIX/qemu +``` +Additional information: +The `configure` script has `break;` in a conditional, where `:` would suffice (or the conditional could just be negated) diff --git a/results/classifier/118/graphic/1404 b/results/classifier/118/graphic/1404 new file mode 100644 index 000000000..97685ae23 --- /dev/null +++ b/results/classifier/118/graphic/1404 @@ -0,0 +1,44 @@ +graphic: 0.976 +performance: 0.945 +x86: 0.900 +device: 0.874 +ppc: 0.834 +assembly: 0.832 +boot: 0.723 +architecture: 0.717 +PID: 0.676 +VMM: 0.604 +vnc: 0.597 +register: 0.595 +debug: 0.547 +permissions: 0.535 +virtual: 0.531 +files: 0.504 +semantic: 0.487 +kernel: 0.454 +socket: 0.433 +mistranslation: 0.415 +hypervisor: 0.412 +user-level: 0.394 +risc-v: 0.368 +network: 0.335 +peripherals: 0.313 +i386: 0.245 +TCG: 0.214 +arm: 0.200 +KVM: 0.049 + +qemu-7.2: virtio-blk-pci I/O errors with detect-zeroes=unmap +Description of problem: +Since upgrading from qemu-7.1 to qemu-7.2 I have seen many anomalies with VMs that use the virtio-blk-pci device for the root filesystem and the `detect-zeroes=unmap` option, typically in the form of I/O errors or huge decreases in read/write performance. This has been observed for both pre-existing Linux & Windows systems using the QCOW2 disk format, and a freshly created Linux system. + +* For an existing x86_64 Windows-10 guest system, hosted on Debian-11, the guest system takes many minutes to boot and Task Manager shows the virtual disk showing read/write latencies measured in seconds rather than milliseconds. +* Attempts to create a new x86_64 Debian-11 guest on a Debian-11 host produce an input/output error when trying to partition the QCOW2 hard disk /dev/vda (as per attached screenshot)  +* Using a pre-existing Debian-11 guest that works perfectly with qemu-7.1, fails to format a basic ext3 /dev/loop filesystem when this guest is booted with qemu-7.2, giving `mke2fs: Input/output error while writing out and closing file system` +Steps to reproduce: +(installer error) +1. Create fresh QCOW2 image: `qemu-img create -f qcow2 deb11.img 8G` +2. Run standard Debian-11 installer from ISO image and virtio-blk-pci drive and options `-drive if=none,media=disk,id=drive0,file=deb11.img,cache=writeback,discard=unmap,detect-zeroes=unmap` +3. Use default options with "guided partitioning" +Additional information: +I'm not aware of any changes to the setup of my system that would account for these problems, and have successfully tried many similar experiments with QEMU version up to and including version 7.1. Obviously, I'm hoping there's some trivial configuration error I've overlooked in qemu-7.2 - any suggestions would be much appreciated. diff --git a/results/classifier/118/graphic/1404690 b/results/classifier/118/graphic/1404690 new file mode 100644 index 000000000..aeb4c0119 --- /dev/null +++ b/results/classifier/118/graphic/1404690 @@ -0,0 +1,165 @@ +graphic: 0.890 +TCG: 0.867 +semantic: 0.848 +arm: 0.846 +risc-v: 0.828 +ppc: 0.795 +architecture: 0.785 +virtual: 0.782 +hypervisor: 0.769 +assembly: 0.767 +KVM: 0.765 +peripherals: 0.763 +vnc: 0.761 +PID: 0.760 +mistranslation: 0.755 +permissions: 0.754 +performance: 0.753 +register: 0.748 +VMM: 0.748 +kernel: 0.743 +boot: 0.737 +device: 0.737 +x86: 0.733 +network: 0.708 +socket: 0.692 +user-level: 0.684 +debug: 0.636 +files: 0.625 +i386: 0.580 + +Qemu crashes with chrooted m68k + +I'm using qemu-m68k 2.2.0 to chroot into a m68k coldfire linux, which works fine on the coldfire machine. + +I've been able to use binfmt_msc and used the above code to use qemu with strace: + +#include <unistd.h> +#include <string.h> + +int main(int argc, char **argv, char **envp) { + char *newargv[argc + 4]; + + newargv[0] = argv[0]; + newargv[1] = "-cpu"; + newargv[2] = "cfv4e"; + newargv[3] = "-strace"; + + memcpy(&newargv[4], &argv[1], sizeof(*argv) * (argc - 1)); + newargv[argc + 3] = NULL; + return execve("/usr/bin/qemu-m68k", newargv, envp); +} + +Everything works fine. I can run bash, busybox, ash, but when I try to run a ls or just type an invalid command, I got the attached sequence of messages, which end like so: + +11351 waitpid(-1,0xf6fffa00,0x3) = -1 errno=10 (No child processes) +qemu: fatal: Illegal instruction: 0000 @ f6fffa30 +D0 = ffffffff A0 = f67dcf50 F0 = 0000000000000000 ( 0) +D1 = 0000000a A1 = f66e0898 F1 = 0000000000000000 ( 0) +D2 = f6fffaa8 A2 = f67df268 F2 = 0000000000000000 ( 0) +D3 = 00000000 A3 = 00000000 F3 = 0000000000000000 ( 0) +D4 = 00000008 A4 = 800026c4 F4 = 0000000000000000 ( 0) +D5 = 00000000 A5 = f67d98e0 F5 = 0000000000000000 ( 0) +D6 = f6fffaa8 A6 = f6fffa7c F6 = 0000000000000000 ( 0) +D7 = 00000002 A7 = f6fffa24 F7 = 0000000000000000 ( 0) +PC = f6fffa30 SR = 0000 ----- FPRESULT = 0 +Aborted + +How can I debug it further to try to figure out if this is a qemu issue or not? Thanks + + + +On 21 December 2014 at 16:21, Michel Boaventura +<email address hidden> wrote: +> Everything works fine. I can run bash, busybox, ash, but when I try to +> run a ls or just type an invalid command, I got the attached sequence of +> messages, which end like so: +> +> 11351 waitpid(-1,0xf6fffa00,0x3) = -1 errno=10 (No child processes) +> qemu: fatal: Illegal instruction: 0000 @ f6fffa30 +> D0 = ffffffff A0 = f67dcf50 F0 = 0000000000000000 ( 0) +> D1 = 0000000a A1 = f66e0898 F1 = 0000000000000000 ( 0) +> D2 = f6fffaa8 A2 = f67df268 F2 = 0000000000000000 ( 0) +> D3 = 00000000 A3 = 00000000 F3 = 0000000000000000 ( 0) +> D4 = 00000008 A4 = 800026c4 F4 = 0000000000000000 ( 0) +> D5 = 00000000 A5 = f67d98e0 F5 = 0000000000000000 ( 0) +> D6 = f6fffaa8 A6 = f6fffa7c F6 = 0000000000000000 ( 0) +> D7 = 00000002 A7 = f6fffa24 F7 = 0000000000000000 ( 0) +> PC = f6fffa30 SR = 0000 ----- FPRESULT = 0 +> Aborted +> +> How can I debug it further to try to figure out if this is a qemu issue +> or not? Thanks + +This is almost certainly a QEMU bug -- m68k/Coldfire is +unmaintained upstream right now. + +I would start debugging this with QEMU's -d and -D options: +you can use "-d in_asm,exec,cpu -D logfile.out" to write +a lot of logging information about the guest code QEMU executes. +(This can be a huge volume, so best to use the shortest possible +reproducing command. Take out 'exec' if it's really too slow.) +Then you can see what the code the guest executed was and figure +out what happened. Alternatively you can try using qemu's +debug stub: pass QEMU "-g 1234" and then connect a coldfire gdb +using gdb's "target remote :1234" command. Either way, what you +want to find out is what exactly happened in the instructions +between the waitpid and the crash. + +My current guess is that either we've messed up the waitpid +(seems unlikely, it's not very complicated), or we're not +getting signal handling right (much more complicated and +likely to have bugs): your crash happens at about the point +where the shell is due to receive a SIGCHLD for the child +process it spawned. If you send the shell a signal in some +other way (eg type ctrl-C at it, or send it a SIGINT from +outside QEMU) does it die in a similar way? + +PS: an easier way to enable strace for linux-user in a binfmt-misc +chroot is to use the QEMU_STRACE environment variable. (All the +linux-user command line options have environment variable versions; +check --help.) + +You can also just use a command like + 'chroot my-chroot /usr/bin/qemu-m68k-static -strace /bin/sh -c /bin/ls' +for a one-off command run. + +-- PMM + + +Oh, if you're able to put your chroot up for download somewhere so I can reproduce the problem, I can have a look at it for you. (I don't otherwise have a coldfire chroot or toolchain.) + + +Hi Peter, + +Thanks for you time! I've attached my mini chroot environment. As you can see, it is very minimal, but enough to be chrooted and to test this. I will try your suggestions in a couple of days, but if you could please try it before, I will really appreciate. + +Michel + +I have a fix for this (our code for setting up the signal return trampoline used the wrong types and only worked on 32 bit hosts). + +I notice that /bin/ls can't ls directories (it seems ok with single files) but that's a different bug. + + +Patch fixing this: https://patchwork.ozlabs.org/patch/423460/ + + +I've identified the cause of "ls" not returning any output, but I don't think we can fix it in QEMU. + +This happens if the host fs is ext3 or ext4 on a 64 bit system. Here the "d_off" entry in a linux_dirent64 is actually a hashtable hash, and so can be a full 64 bits. Unfortunately the guest binary here is trying to convert getdents64() syscall return information into a dirent with only a 32 bit offset field, and so it (guest libc, I think) just ignores dirents with offsets >4GB, which is all of them. + +Sadly although ext3/4 support an f_mode bit for "make hash offsets fit in 32 bit", this is only for the benefit of kernel internal APIs (it's used by NFS) and AFAICT can't be set by userspace. So I can't at the moment think of any way for QEMU to deal with this... + + +Hi Peter, + +Thank you very much for your help, I really appreciate it. I've tested both your patch and your workaround to make ls work (I've created a xfs partition to put my image) and everything works greatly. + +Merry Xmas. + +Michel + +Peter's patch had been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=1669add752d9f2928 +==> Fix released + diff --git a/results/classifier/118/graphic/1410 b/results/classifier/118/graphic/1410 new file mode 100644 index 000000000..a068abcd7 --- /dev/null +++ b/results/classifier/118/graphic/1410 @@ -0,0 +1,44 @@ +graphic: 0.920 +boot: 0.843 +architecture: 0.758 +device: 0.740 +arm: 0.623 +performance: 0.617 +PID: 0.458 +files: 0.410 +ppc: 0.385 +permissions: 0.380 +semantic: 0.377 +debug: 0.321 +register: 0.275 +socket: 0.264 +TCG: 0.233 +mistranslation: 0.168 +vnc: 0.165 +peripherals: 0.152 +VMM: 0.151 +kernel: 0.081 +user-level: 0.070 +i386: 0.041 +network: 0.036 +risc-v: 0.025 +hypervisor: 0.021 +KVM: 0.016 +virtual: 0.012 +assembly: 0.011 +x86: 0.007 + +system_powerdown only works once +Description of problem: +When the guest is configured to sleep on power button events, something in the ACPI states are not restored coming out of resume. The first call to `system_powerdown` succeeds, but the second after waking the system is rejected in `acpi_pm1_evt_power_down()` since `ar->pm1.evt.en` is zero coming out of the resume path. + +There is probably something deeper (or perhaps in seabios?) since removing the test in that handler doesn't cause a second sleep either. +Steps to reproduce: + +1. Boot a guest configured to sleep when it receives a power button event +2. `system_powerdown` from the monitor to tell it to sleep +3. `info status` to verify that it is suspended +4. Wake the guest, either with `system_wakeup` or moving the mouse or something +5. `system_powerdown` has no effect +Additional information: +This is using qemu-7.2.0 built from source with a Windows 10 guest and IGD GPU+audio passthrough. diff --git a/results/classifier/118/graphic/1416988 b/results/classifier/118/graphic/1416988 new file mode 100644 index 000000000..dbc202c07 --- /dev/null +++ b/results/classifier/118/graphic/1416988 @@ -0,0 +1,65 @@ +graphic: 0.895 +performance: 0.839 +architecture: 0.823 +kernel: 0.790 +semantic: 0.752 +device: 0.724 +ppc: 0.723 +debug: 0.626 +files: 0.597 +TCG: 0.596 +PID: 0.587 +network: 0.564 +vnc: 0.555 +register: 0.553 +socket: 0.542 +mistranslation: 0.505 +risc-v: 0.484 +arm: 0.463 +peripherals: 0.415 +permissions: 0.403 +VMM: 0.358 +user-level: 0.340 +assembly: 0.334 +hypervisor: 0.319 +boot: 0.298 +x86: 0.288 +i386: 0.234 +virtual: 0.189 +KVM: 0.188 + +Wrong signal handling in qemu-aarch64. + +Running GCC 5.0 testsuite under qemu-aarch64, I noticed that tests connected with stack unwinding fail with: + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +or run into infinite loop. + +Here is one example: + +$ /home/max/build/gcc-aarch64/gcc/xgcc -B/home/max/build/gcc-aarch64/gcc/ /home/max/src/toolchain/gcc/gcc/testsuite/gcc.dg/cleanup-11.c -fexceptions -fnon-call-exceptions -O2 -lm -o ./cleanup-11.exe + +$ qemu-aarch64 -L /home/max/install/aarch64/aarch64-linux/sys-root/ -R 0 -/cleanup-11.exe +qemu: uncaught target signal 11 (Segmentation fault) - core dumped. + +Actually, this caused by ABI incompatibility between Linux Kernel (trunk) and qemu-aarch64. In fact, size of siginfo structure in Linux and target_siginfo structure in qemu-aarch64 differ: + +sizeof (struct target_siginfo) = 136 // QEMU +sizeof (struct siginfo) = 128 // Linux Kernel + + +This caused by wrong TARGET_SI_PAD_SIZE defined in linux-user/syscall_defs.h: + +#define TARGET_SI_PAD_SIZE ((TARGET_SI_MAX_SIZE/sizeof(int)) - 3) + +In Kernel respective value is: + +#define SI_PAD_SIZE ((SI_MAX_SIZE - __ARCH_SI_PREAMBLE_SIZE) / sizeof(int)) +............................................. +#define __ARCH_SI_PREAMBLE_SIZE (4 * sizeof(int)) // for Aarch64 + +Trivial fix, changing TARGET_SI_PAD_SIZE to right value, is attached. + + + diff --git a/results/classifier/118/graphic/1419 b/results/classifier/118/graphic/1419 new file mode 100644 index 000000000..bbfbf1e31 --- /dev/null +++ b/results/classifier/118/graphic/1419 @@ -0,0 +1,122 @@ +graphic: 0.912 +register: 0.880 +performance: 0.877 +semantic: 0.866 +VMM: 0.860 +debug: 0.854 +hypervisor: 0.839 +TCG: 0.836 +virtual: 0.835 +device: 0.824 +risc-v: 0.824 +mistranslation: 0.824 +permissions: 0.824 +architecture: 0.820 +arm: 0.817 +assembly: 0.817 +network: 0.815 +vnc: 0.803 +KVM: 0.800 +ppc: 0.797 +PID: 0.795 +user-level: 0.773 +peripherals: 0.748 +kernel: 0.739 +boot: 0.723 +socket: 0.706 +x86: 0.697 +files: 0.640 +i386: 0.551 + +Overflow in xlnx_dp_aux_push_rx_fifo() +Description of problem: +Pushing stuff into s->rx_fifo many times make s->rx_fifo overflow. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-aarch64 + +cat << EOF | $QEMU \ +-machine xlnx-zcu102 -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writel 0xfd4a0100 0x7fb141e6 +writel 0xfd4a0100 0x7fb141e6 +writel 0xfd4a0100 0x7fb141e6 +EOF +``` +Additional information: +``` +root@3728b1f90dbd:~/bugs/metadata/xlnx_dp-03# bash -x xlnx_dp-03.videzzo ++ DEFAULT_INPUT_MAXSIZE=10000000 ++ ./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp -max_len=10000000 -detect_leaks=0 poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp-crash-a6a2bd23ff0408dd50652670fdcdf9f5ceaab95d.minimized +==767==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x55d36d8b3870). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1781001818 +INFO: Loaded 1 modules (618604 inline 8-bit counters): 618604 [0x55d370a12000, 0x55d370aa906c), +INFO: Loaded 1 PC tables (618604 PCs): 618604 [0x55d3700a0ce0,0x55d370a113a0), +./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +Matching objects by name , *.core*, *.v_blend*, *.av_buffer_manager*, *.audio* +This process will fuzz the following MemoryRegions: + * xlnx.v-dp.core[0] (size 3b0) + * xlnx.v-dp.v_blend[0] (size 1e0) + * xlnx.v-dp.audio[0] (size 50) + * xlnx.v-dp.av_buffer_manager[0] (size 238) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * xlnx.v-dp.core, EVENT_TYPE_MMIO_READ, 0xfd4a0000 +0x3b0, 4,4 + * xlnx.v-dp.core, EVENT_TYPE_MMIO_WRITE, 0xfd4a0000 +0x3b0, 4,4 + * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_READ, 0xfd4aa000 +0x1e0, 4,4 + * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_WRITE, 0xfd4aa000 +0x1e0, 4,4 + * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_READ, 0xfd4ab000 +0x238, 4,4 + * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_WRITE, 0xfd4ab000 +0x238, 4,4 + * xlnx.v-dp.audio, EVENT_TYPE_MMIO_READ, 0xfd4ac000 +0x50, 1,4 + * xlnx.v-dp.audio, EVENT_TYPE_MMIO_WRITE, 0xfd4ac000 +0x50, 1,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 492Mb +Running: poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp-crash-a6a2bd23ff0408dd50652670fdcdf9f5ceaab95d.minimized +qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: ../util/fifo8.c:43: void fifo8_push_all(Fifo8 *, const uint8_t *, uint32_t): Assertion `fifo->num + num <= fifo->capacity' failed. +==767== ERROR: libFuzzer: deadly signal + #0 0x55d368c8c10e in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x55d368bdad81 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x55d368bb3cb6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x55d368bb3d82 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x55d368bb3d82 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7f9897d8741f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7f9897b9900a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7f9897b9900a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7f9897b78858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7f9897b78728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7f9897b89fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x55d36d56bff3 in fifo8_push_all /root/videzzo/videzzo_qemu/qemu/build-san-6/../util/fifo8.c:43:5 + #12 0x55d3695e64d3 in xlnx_dp_aux_push_rx_fifo /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:436:5 + #13 0x55d3695e1e9a in xlnx_dp_aux_set_command /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:513:13 + #14 0x55d3695dea92 in xlnx_dp_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:805:9 + #15 0x55d36c866ef3 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5 + #16 0x55d36c866831 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18 + #17 0x55d36c865156 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16 + #18 0x55d36c8f330e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23 + #19 0x55d36c8e144b in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12 + #20 0x55d36c8e0f08 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18 + #21 0x55d368ccc0cb in qemu_writel /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1088:5 + #22 0x55d368cca544 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1229:28 + #23 0x55d36d8af22f in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5 + #24 0x55d36d8a65ab in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9 + #25 0x55d36d8a6480 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9 + #26 0x55d368cd310c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1504:12 + #27 0x55d36d8b3b12 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18 + #28 0x55d368bb4826 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #29 0x55d368b97454 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #30 0x55d368ba23fe in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #31 0x55d368b8e9e6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #32 0x7f9897b7a082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #33 0x55d368b8ea3d in _start (/root/bugs/metadata/xlnx_dp-03/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp+0x3291a3d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +0x1,0x9,0x0,0x1,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0xe6,0x41,0xb1,0x7f,0x0,0x0,0x0,0x0,0x1,0x9,0x0,0x1,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0xe6,0x41,0xb1,0x7f,0x0,0x0,0x0,0x0,0x1,0x9,0x0,0x1,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0xe6,0x41,0xb1,0x7f,0x0,0x0,0x0,0x0, +\x01\x09\x00\x01J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\xe6A\xb1\x7f\x00\x00\x00\x00\x01\x09\x00\x01J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\xe6A\xb1\x7f\x00\x00\x00\x00\x01\x09\x00\x01J\xfd\x00\x00\x00\x00\x04\x00\x00\x00\xe6A\xb1\x7f\x00\x00\x00\x00 +``` diff --git a/results/classifier/118/graphic/1420 b/results/classifier/118/graphic/1420 new file mode 100644 index 000000000..6bf4c253d --- /dev/null +++ b/results/classifier/118/graphic/1420 @@ -0,0 +1,69 @@ +graphic: 0.851 +architecture: 0.824 +device: 0.736 +ppc: 0.686 +peripherals: 0.678 +files: 0.591 +kernel: 0.565 +performance: 0.559 +PID: 0.555 +virtual: 0.549 +socket: 0.532 +user-level: 0.496 +debug: 0.440 +mistranslation: 0.432 +x86: 0.404 +hypervisor: 0.392 +assembly: 0.382 +permissions: 0.363 +register: 0.351 +semantic: 0.349 +TCG: 0.282 +vnc: 0.280 +network: 0.255 +VMM: 0.227 +boot: 0.165 +risc-v: 0.129 +arm: 0.105 +KVM: 0.084 +i386: 0.074 + +Missing path for pkg-config on amd64 debian based distros +Description of problem: +This error occurs when attempting to configure qemu from git : +```error +ERROR: glib-2.56 gthread-2.0 is required to compile QEMU +``` + +Although it seems to be as simple as "_just install the dev lib!!!_" it is not that simple. + +1. First of all, my system already has the library installed : + ```sh + dpkg -l | grep libglib2.0-dev + ii libglib2.0-dev:amd64 2.74.4-1 amd64 Development files for the GLib library + ii libglib2.0-dev-bin 2.74.4-1 amd64 Development utilities for the GLib library + ``` +1. Second, the file required by _pkg-config_ does exist aswell : + ```sh + ls /usr/lib/x86_64-linux-gnu/pkgconfig/gthread-2.0.pc -l + -rw-r--r-- 1 root root 240 dez 27 20:42 /usr/lib/x86_64-linux-gnu/pkgconfig/gthread-2.0.pc + ``` +1. Finally, the real problem is that pkg-config is not able to identify it **unless** you specify the _x86-64_ dir : + - Default usage. It fails. + ```sh + pkg-config --modversion gthread-2.0 + Package gthread-2.0 was not found in the pkg-config search path. + Perhaps you should add the directory containing `gthread-2.0.pc' + to the PKG_CONFIG_PATH environment variable + Package 'gthread-2.0', required by 'virtual:world', not found + ``` + - Fixed usage (temp) + ```sh + env PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/lib/x86_64-linux-gnu/pkgconfig/" pkg-config --modversion gthread-2.0 + 2.74.4 + ``` +Steps to reproduce: +1. clone qemu (master) +2. try to run _configure_ +Additional information: +Of course it seems to be a problem related to the program _pkg-config_ itself, or even by the distro's package, but it totally prevents any build of qemu in a debian-based distro, with architecture _amd64_. diff --git a/results/classifier/118/graphic/1423 b/results/classifier/118/graphic/1423 new file mode 100644 index 000000000..4c934e6ec --- /dev/null +++ b/results/classifier/118/graphic/1423 @@ -0,0 +1,43 @@ +graphic: 0.913 +device: 0.907 +architecture: 0.813 +x86: 0.802 +PID: 0.791 +semantic: 0.726 +kernel: 0.688 +hypervisor: 0.681 +debug: 0.632 +permissions: 0.629 +boot: 0.621 +TCG: 0.614 +performance: 0.610 +ppc: 0.574 +files: 0.567 +i386: 0.564 +vnc: 0.549 +user-level: 0.533 +register: 0.530 +mistranslation: 0.509 +risc-v: 0.480 +socket: 0.475 +VMM: 0.473 +arm: 0.472 +assembly: 0.469 +network: 0.423 +peripherals: 0.335 +virtual: 0.291 +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/118/graphic/1435 b/results/classifier/118/graphic/1435 new file mode 100644 index 000000000..2dc7a82ed --- /dev/null +++ b/results/classifier/118/graphic/1435 @@ -0,0 +1,46 @@ +graphic: 0.986 +TCG: 0.952 +semantic: 0.941 +performance: 0.909 +ppc: 0.866 +user-level: 0.798 +device: 0.796 +PID: 0.779 +files: 0.779 +socket: 0.777 +debug: 0.756 +architecture: 0.726 +network: 0.695 +kernel: 0.668 +register: 0.659 +permissions: 0.653 +vnc: 0.607 +peripherals: 0.606 +hypervisor: 0.560 +VMM: 0.548 +risc-v: 0.544 +assembly: 0.500 +boot: 0.491 +arm: 0.471 +x86: 0.462 +mistranslation: 0.411 +virtual: 0.406 +i386: 0.311 +KVM: 0.258 + +Infinite recursion in tcg_gen_mulu2_i32 for certain 32-bit hosts. +Description of problem: +`tcg_gen_mulu2_i32` infinitely recurses on a 32-bit host (TCG target) that has neither `TCG_TARGET_HAS_mulu2_i32` nor `TCG_TARGET_HAS_muluh_i32`. + +I don't actually think there is any host that is 32-bits and has neither mulu2 nor muluh. The only reference I found is [this](https://gitlab.com/qemu-project/qemu/-/commit/df9ebea53ebc1c98217743f56c30ae3a46031bb9) commit, which adds an `#error` if that situation is hit. But the check, which [still exists](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/include/tcg/tcg.h#L174), checks if those flags are *defined*, not for their value. I guess, over the years as the code was refactored, the check wasn't updated because, frankly, there aren't any hosts that match that situation (except mine). + +One easy fix is to change the check mentioned above to check the actual macro value so that compilation fails. I can create a PR for that. +Steps to reproduce: +(Note: I'm linking to the v7.2.0 tag so that these links stay relevant). + +1. `tcg_gen_mulu2_i32` [calls](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L890) `tcg_gen_mul_i64`. +2. `tcg_gen_mul_i64` on 32-bit hosts, due to [this](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1097) check for `TCG_TARGET_REG_BITS == 32`, is defined [here](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1218), and [calls](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1226) `tcg_gen_mulu2_i32`. +3. Rinse and repeat. +4. Eventually, as gen_mulu2/mul functions spill while trying to allocate temps, they will overflow the TB buffer. This will restart code generation with smaller and smaller block sizes, until the block size reaches 1 instruction. TCG will then give up and [assert](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/accel/tcg/translate-all.c#L869). +Additional information: + diff --git a/results/classifier/118/graphic/1435973 b/results/classifier/118/graphic/1435973 new file mode 100644 index 000000000..5c9c99a00 --- /dev/null +++ b/results/classifier/118/graphic/1435973 @@ -0,0 +1,94 @@ +graphic: 0.964 +i386: 0.956 +kernel: 0.949 +architecture: 0.944 +performance: 0.922 +peripherals: 0.922 +files: 0.921 +user-level: 0.909 +vnc: 0.894 +socket: 0.893 +device: 0.890 +ppc: 0.879 +PID: 0.863 +assembly: 0.857 +permissions: 0.854 +x86: 0.811 +network: 0.790 +mistranslation: 0.790 +debug: 0.784 +register: 0.773 +VMM: 0.764 +semantic: 0.752 +arm: 0.747 +boot: 0.742 +hypervisor: 0.717 +TCG: 0.707 +virtual: 0.698 +risc-v: 0.692 +KVM: 0.631 + +Qemu crash when a guest linux issues specific scsi command via ioctl(SG_IO) with SCSI disk emulation. + +As of git revision 362ca922eea03240916287a8a6267801ab095d12, when guest linux issues specifit scsi command, qemu crashes. + +To reproduce. + +1. launch qemu with scsi emulatoin +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 +2. issues scsi command via ioctl(SG_IO) on guest linux. like below. + +------------------------- +struct request_sense sens; +struct sg_io_hdr sg; +unsigned char cdb[6]; +unsigned char buf[127]; + +memset( &sens, 0, sizeof(sens) ); +memset(&sg, 0, sizeof(sg)); +memset(cdb, 0, sizeof(cdb)); +memset(buf, 0, sizeof(buf)); + +// qemu crash!!! +cdb[0] = 0xff; + +sg.dxferp = buf; +sg.dxfer_len = sizeof(buf); +sg.dxfer_direction = SG_DXFER_FROM_DEV; +sg.flags = 0; +sg.interface_id = 'S'; +sg.cmdp = cdb; +sg.cmd_len = sizeof( cdb ); +sg.sbp = (unsigned char*)&sens; +sg.mx_sb_len = sizeof( sens ); + +ioctl( fd, SG_IO, &sg ); +------------------------- + +I think cause is below code. + +scsi-bus.c L1239 +int scsi_req_parse_cdb(SCSIDevice *dev, SCSICommand *cmd, uint8_t *buf) +{ + int rc; + + cmd->lba = -1; + cmd->len = scsi_cdb_length(buf); + ... + memcpy(cmd->buf, buf, cmd->len); +} + +scsi_cdb_length(buf) returns -1 when buf[0] is unexpected value. +Then memcpy(cmd->buf, buf, 4294967295); is executed and crash. + +Environment +Qemu: git revision 362ca922eea03240916287a8a6267801ab095d12 +Guest: linux kernel 3.18.4 + buildroot +Host: Windows 7 64bit + +Thanks, +hiroaki + +Looks like this has been fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=c170aad8b057223b1139d7 + diff --git a/results/classifier/118/graphic/1437 b/results/classifier/118/graphic/1437 new file mode 100644 index 000000000..a3f0baa18 --- /dev/null +++ b/results/classifier/118/graphic/1437 @@ -0,0 +1,36 @@ +graphic: 0.977 +boot: 0.945 +device: 0.842 +performance: 0.569 +files: 0.381 +arm: 0.364 +network: 0.345 +semantic: 0.295 +socket: 0.282 +risc-v: 0.262 +debug: 0.226 +architecture: 0.216 +permissions: 0.193 +vnc: 0.190 +mistranslation: 0.152 +TCG: 0.130 +x86: 0.128 +i386: 0.126 +register: 0.122 +user-level: 0.117 +hypervisor: 0.108 +PID: 0.100 +VMM: 0.074 +KVM: 0.042 +kernel: 0.041 +assembly: 0.040 +virtual: 0.032 +peripherals: 0.021 +ppc: 0.016 + +Nitrux doesn't finish boot process +Description of problem: +Boot process doesn't finish + +Steps to reproduce: +1.Load Nitrux ISO diff --git a/results/classifier/118/graphic/1439 b/results/classifier/118/graphic/1439 new file mode 100644 index 000000000..44d828784 --- /dev/null +++ b/results/classifier/118/graphic/1439 @@ -0,0 +1,41 @@ +graphic: 0.886 +device: 0.842 +KVM: 0.775 +files: 0.736 +network: 0.692 +performance: 0.598 +kernel: 0.586 +x86: 0.558 +socket: 0.542 +semantic: 0.533 +architecture: 0.480 +vnc: 0.458 +boot: 0.444 +register: 0.440 +ppc: 0.426 +peripherals: 0.399 +arm: 0.328 +debug: 0.284 +hypervisor: 0.274 +PID: 0.231 +TCG: 0.231 +VMM: 0.208 +risc-v: 0.188 +user-level: 0.181 +i386: 0.169 +virtual: 0.119 +mistranslation: 0.113 +permissions: 0.109 +assembly: 0.064 + +QEMU crashes when there is an "[accel]" section in the config file +Description of problem: +QEMU crashes with a segmentation fault if there is a "[accel]" section in the config file with a type="kvm" entry. It would be maybe still be OK if there was an error message instead, but it should certainly not crash. +Steps to reproduce: +``` +$ cat > /tmp/config <<EOF +[accel] +type = "kvm" +EOF +$ qemu-system-x86_64 -readconfig /tmp/config +``` diff --git a/results/classifier/118/graphic/1439800 b/results/classifier/118/graphic/1439800 new file mode 100644 index 000000000..e490359e4 --- /dev/null +++ b/results/classifier/118/graphic/1439800 @@ -0,0 +1,43 @@ +graphic: 0.933 +device: 0.895 +performance: 0.666 +architecture: 0.653 +mistranslation: 0.637 +network: 0.628 +boot: 0.620 +semantic: 0.610 +vnc: 0.456 +hypervisor: 0.444 +files: 0.439 +kernel: 0.427 +debug: 0.417 +peripherals: 0.404 +risc-v: 0.379 +socket: 0.352 +PID: 0.351 +ppc: 0.333 +register: 0.333 +user-level: 0.304 +VMM: 0.302 +permissions: 0.301 +TCG: 0.292 +x86: 0.273 +virtual: 0.239 +i386: 0.238 +arm: 0.198 +assembly: 0.188 +KVM: 0.126 + +GTK fullscreen mode start stretched but fixes after leaving and returning full screen mode + +I'm running QEMU 2.2.91 compiled directly from git and starting QEMU with the -full-screen option. The guest OS is Windows 8.1 using the VGA driver from QEMU. + +The image can be fixed leaving the full-screen mode and returning it back. So it appears that QEMU loses the information with multiple resolution changes of the boot process and fails in the end. + +The description can be a little confusing, so I've put a video on Youtube, so it can demonstrate the real issue: +https://www.youtube.com/watch?v=-lWbWEUOSsk + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU and the latest version of GTK? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1451067 b/results/classifier/118/graphic/1451067 new file mode 100644 index 000000000..6c50dcfbb --- /dev/null +++ b/results/classifier/118/graphic/1451067 @@ -0,0 +1,83 @@ +x86: 0.955 +graphic: 0.923 +network: 0.913 +architecture: 0.873 +permissions: 0.800 +device: 0.788 +mistranslation: 0.784 +PID: 0.767 +debug: 0.767 +semantic: 0.765 +performance: 0.757 +user-level: 0.743 +socket: 0.732 +files: 0.721 +arm: 0.712 +kernel: 0.669 +ppc: 0.665 +hypervisor: 0.659 +boot: 0.623 +peripherals: 0.604 +risc-v: 0.578 +vnc: 0.568 +register: 0.550 +virtual: 0.539 +TCG: 0.515 +assembly: 0.497 +VMM: 0.491 +KVM: 0.436 +i386: 0.396 + +-smb option requires full path for Samba sharing to work + +This issue has been reported on qemu-devel a looong time ago: https://lists.gnu.org/archive/html/qemu-devel/2005-12/msg00141.html + +QEMU version 2.2.1-4 on Arch Linux x86_64 + +Steps to reproduce: + +host$ mkdir share +host$ chmod o+rwx share +host$ qemu <other options> -smb share + +vm$ smbclient //10.0.2.4/qemu -N +smbclient: Can't load /etc/samba/smb.conf - run testparm to debug it +Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.2.1] +tree connect failed: NT_STATUS_BAD_NETWORK_NAME +vm$ poweroff + +Workaround: + +host$ qemu <other options> -smb /full/path/to/share + +vm$ $ smbclient //10.0.2.4/qemu -N +smbclient: Can't load /etc/samba/smb.conf - run testparm to debug it +Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.2.1] +smb: \> ls + . D 0 Sat May 2 19:57:31 2015 + .. D 0 Sat May 2 19:57:31 2015 + + 961302540 blocks of size 1024. 637557248 blocks available +smb: \> quit + +Please, please fix this gotcha, whether in the documentation or in code. it can cause some serious bouts of hair-pulling. + +-Alain + +On my system, `qemu` is an alias for `qemu-system-x86_64`. + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1455 b/results/classifier/118/graphic/1455 new file mode 100644 index 000000000..1d010a6bc --- /dev/null +++ b/results/classifier/118/graphic/1455 @@ -0,0 +1,33 @@ +graphic: 0.960 +device: 0.928 +performance: 0.835 +architecture: 0.835 +debug: 0.742 +semantic: 0.659 +peripherals: 0.537 +i386: 0.461 +arm: 0.432 +mistranslation: 0.338 +assembly: 0.312 +user-level: 0.293 +virtual: 0.270 +network: 0.256 +ppc: 0.208 +PID: 0.185 +risc-v: 0.157 +files: 0.117 +vnc: 0.110 +permissions: 0.102 +socket: 0.091 +x86: 0.066 +VMM: 0.042 +boot: 0.038 +register: 0.032 +hypervisor: 0.024 +TCG: 0.019 +kernel: 0.009 +KVM: 0.003 + +copy-paste not working +Description of problem: +copy-paste not working under Sway (wayland - wlroots) when I use `-display gtk`. This was broken recently. I have `spice-vdagent` as well as `spice-vdagentd` running properly in the guest, still copy-paste not working. diff --git a/results/classifier/118/graphic/1468 b/results/classifier/118/graphic/1468 new file mode 100644 index 000000000..0ea21a368 --- /dev/null +++ b/results/classifier/118/graphic/1468 @@ -0,0 +1,36 @@ +graphic: 0.953 +virtual: 0.931 +performance: 0.923 +debug: 0.874 +semantic: 0.860 +device: 0.789 +mistranslation: 0.754 +architecture: 0.587 +peripherals: 0.543 +i386: 0.455 +user-level: 0.455 +permissions: 0.448 +boot: 0.413 +register: 0.384 +risc-v: 0.379 +PID: 0.377 +vnc: 0.375 +socket: 0.370 +TCG: 0.368 +network: 0.363 +ppc: 0.345 +VMM: 0.341 +arm: 0.219 +files: 0.174 +hypervisor: 0.170 +kernel: 0.162 +x86: 0.156 +KVM: 0.131 +assembly: 0.128 + +qemu hangs on white windows when connecting to virtual port using -serial option when using Windows OS +Description of problem: +I was trying to connect windbg with a qemu vm. +First I try using named pipes but all the tutorials I found online result in the qemu windows not even showing. So I give up and trying to use virtual COMs to connect the qemu machine with windbg over serial port. So I created using professional Virtual come driver a link between COM2 and COM4. Now I run qemu with -serial COM2 and I do not run windbg than it run correctly and no problem is present. As soon as I run windbg qemu hangs at startup just after the main window is created. The qemu window remains white and windows shows the normal "The application is not responding". It's like the program is in a infinite loop situation. +Also I noted that If I run qemu and not windbg as soon as the other COM port is connected qemu would stop working and remain frozed. Again showing the "The application is not responding". +If instead of qemu I use other "commercial" software with the same setup (of course there I could use named pipes anyway) I can connect windbg with the machine and do the debug session. diff --git a/results/classifier/118/graphic/1469946 b/results/classifier/118/graphic/1469946 new file mode 100644 index 000000000..e1e6dfb8b --- /dev/null +++ b/results/classifier/118/graphic/1469946 @@ -0,0 +1,282 @@ +graphic: 0.847 +permissions: 0.838 +KVM: 0.827 +architecture: 0.824 +assembly: 0.819 +register: 0.819 +device: 0.812 +PID: 0.804 +risc-v: 0.802 +kernel: 0.797 +files: 0.795 +virtual: 0.791 +socket: 0.788 +debug: 0.786 +arm: 0.782 +user-level: 0.778 +hypervisor: 0.778 +performance: 0.774 +network: 0.767 +x86: 0.760 +semantic: 0.759 +VMM: 0.756 +vnc: 0.753 +peripherals: 0.739 +ppc: 0.738 +boot: 0.725 +TCG: 0.716 +mistranslation: 0.704 +i386: 0.483 + +guest can't get IP when create guest with bridge. + +Environment: +------------ +Host OS (ia32/ia32e/IA64):ia32e +Guest OS (ia32/ia32e/IA64):ia32e +Guest OS Type (Linux/Windows):linux +kvm.git Commit:aefbef10e3ae6e2c6e3c54f906f10b34c73a2c66 +qemu.git Commit:dc1e1350f8061021df765b396295329797d66933 +Host Kernel Version:4.1.0 +Hardware:Ivytown_EP, Haswell_EP + + +Bug detailed description: +-------------------------- +when create guest with bridge, the guest can not get ip. + +note: +1. fail rate: 3/5 +2. this is a qemu bug: +kvm + qemu = result +aefbef10 + dc1e1350 = bad +aefbef10 + a4ef02fd = good + +Reproduce steps: +---------------- +1. create guest: +qemu-system-x86_64 -enable-kvm -m 2G -smp 4 -device virtio-net-pci,netdev=net0,mac=$random_mac -netdev tap,id=net0,script=/etc/kvm/qemu-ifup rhel6u5.qcow + +Current result: +---------------- +guest can't get IP + +Expected result: +---------------- +guest can get ip + +Basic root-causing log: +---------------------- + +the first bad commit is +commit a90a7425cf592a3afeff3eaf32f543b83050ee5c +Author: Fam Zheng <email address hidden> +Date: Thu Jun 4 14:45:17 2015 +0800 + + tap: Drop tap_can_send + + This callback is called by main loop before polling s->fd, if it returns + false, the fd will not be polled in this iteration. + + This is redundant with checks inside read callback. After this patch, + the data will be sent to peer when it arrives. If the device can't + receive, it will be queued to incoming_queue, and when the device status + changes, this queue will be flushed. + + Signed-off-by: Fam Zheng <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Stefan Hajnoczi <email address hidden> + +On Tue, 06/30 03:41, chao zhou wrote: +> the first bad commit is +> commit a90a7425cf592a3afeff3eaf32f543b83050ee5c +> Author: Fam Zheng <email address hidden> +> Date: Thu Jun 4 14:45:17 2015 +0800 +> +> tap: Drop tap_can_send +> +> This callback is called by main loop before polling s->fd, if it returns +> false, the fd will not be polled in this iteration. +> +> This is redundant with checks inside read callback. After this patch, +> the data will be sent to peer when it arrives. If the device can't +> receive, it will be queued to incoming_queue, and when the device status +> changes, this queue will be flushed. +> +> Signed-off-by: Fam Zheng <email address hidden> +> Message-id: <email address hidden> +> Signed-off-by: Stefan Hajnoczi <email address hidden> + +Could you try this patch? + +http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg07377.html + +Fam + + +after try the patch http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg07377.html with qemu.git commit(d2966f804d70a244f5dde395fc5d22a50ed3e74e) +the guest can get IP, but after save/retore or live migration, the guest is alive, but ping or ssh guest's IP fail . + +On Wed, 07/01 06:36, chao zhou wrote: +> after try the patch +> http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg07377.html with +> qemu.git commit(d2966f804d70a244f5dde395fc5d22a50ed3e74e) the guest can get +> IP, but after save/retore or live migration, the guest is alive, but ping or +> ssh guest's IP fail . + +Another fix is needed to handle stop/resume. I'm sending it now with you in the +Cc list. Please test! + +Thanks, +Fam + +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1469946 +> +> Title: +> guest can't get IP when create guest with bridge. +> +> Status in QEMU: +> New +> +> Bug description: +> Environment: +> ------------ +> Host OS (ia32/ia32e/IA64):ia32e +> Guest OS (ia32/ia32e/IA64):ia32e +> Guest OS Type (Linux/Windows):linux +> kvm.git Commit:aefbef10e3ae6e2c6e3c54f906f10b34c73a2c66 +> qemu.git Commit:dc1e1350f8061021df765b396295329797d66933 +> Host Kernel Version:4.1.0 +> Hardware:Ivytown_EP, Haswell_EP +> +> +> Bug detailed description: +> -------------------------- +> when create guest with bridge, the guest can not get ip. +> +> note: +> 1. fail rate: 3/5 +> 2. this is a qemu bug: +> kvm + qemu = result +> aefbef10 + dc1e1350 = bad +> aefbef10 + a4ef02fd = good +> +> Reproduce steps: +> ---------------- +> 1. create guest: +> qemu-system-x86_64 -enable-kvm -m 2G -smp 4 -device virtio-net-pci,netdev=net0,mac=$random_mac -netdev tap,id=net0,script=/etc/kvm/qemu-ifup rhel6u5.qcow +> +> Current result: +> ---------------- +> guest can't get IP +> +> Expected result: +> ---------------- +> guest can get ip +> +> Basic root-causing log: +> ---------------------- +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1469946/+subscriptions +> + + +Since commit 6e99c63 "net/socket: Drop net_socket_can_send" and friends, net queues need to be explicitly flushed after qemu_can_send_packet() returns false, because the netdev side will disable the polling of fd. + +This fixes the case of "cont" after "stop" (or migration), i.e. +vm_running changes to true, by listening to vm state changes. + +Signed-off-by: Fam Zheng <email address hidden> +--- + include/net/net.h | 2 ++ + net/net.c | 14 +++++++++++++- + 2 files changed, 15 insertions(+), 1 deletion(-) + +diff --git a/include/net/net.h b/include/net/net.h index 6a6cbef..619a6e1 100644 +--- a/include/net/net.h ++++ b/include/net/net.h +@@ -8,6 +8,7 @@ + #include "net/queue.h" + #include "migration/vmstate.h" + #include "qapi-types.h" ++#include "sysemu/sysemu.h" + + #define MAX_QUEUE_NUM 1024 + +@@ -92,6 +93,7 @@ struct NetClientState { + NetClientDestructor *destructor; + unsigned int queue_index; + unsigned rxfilter_notify_enabled:1; ++ VMChangeStateEntry *vmcse; + }; + + typedef struct NICState { +diff --git a/net/net.c b/net/net.c +index 6ff7fec..edfa6a0 100644 +--- a/net/net.c ++++ b/net/net.c +@@ -43,7 +43,6 @@ + #include "qapi-visit.h" + #include "qapi/opts-visitor.h" + #include "qapi/dealloc-visitor.h" +-#include "sysemu/sysemu.h" + + /* Net bridge is currently not supported for W32. */ #if !defined(_WIN32) @@ -263,6 +262,16 @@ static void qemu_net_client_destructor(NetClientState *nc) + g_free(nc); + } + ++static void qemu_net_client_handle_vmstate(void *opaque, ++ int running, ++ RunState state) { ++ NetClientState *nc = opaque; ++ if (running && qemu_can_send_packet(nc) && nc->peer) { ++ qemu_flush_queued_packets(nc->peer); ++ } ++} ++ + static void qemu_net_client_setup(NetClientState *nc, + NetClientInfo *info, + NetClientState *peer, @@ -287,6 +296,8 @@ static void qemu_net_client_setup(NetClientState *nc, + + nc->incoming_queue = qemu_new_net_queue(nc); + nc->destructor = destructor; ++ nc->vmcse = qemu_add_vm_change_state_handler(qemu_net_client_handle_vmstate, ++ nc); + } + + NetClientState *qemu_new_net_client(NetClientInfo *info, @@ -395,6 +406,7 @@ void qemu_del_net_client(NetClientState *nc) + MAX_QUEUE_NUM); + assert(queues != 0); + ++ qemu_del_vm_change_state_handler(nc->vmcse); + /* If there is a peer NIC, delete and cleanup client, but do not free. */ + if (nc->peer && nc->peer->info->type == NET_CLIENT_OPTIONS_KIND_NIC) { + NICState *nic = qemu_get_nic(nc->peer); +-- +2.4.3 + + + +after try this patch and http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg07377.html with qemu.git d2966f804d70a244f5dde395fc5d22a50ed3e74e + after save/retore or live migration, the guest is alive, ping or ssh guest's IP , it is fine + + +Does the bug's patch has merged in qemu.git? +I test the latest qemu.git(commit:5b5e8cdd7da7a2214dd062afff5b866234aab228), the bug still can reproduce. + +On Mon, Jul 20, 2015 at 07:46:55AM -0000, chao zhou wrote: +> Does the bug's patch has merged in qemu.git? +> I test the latest qemu.git(commit:5b5e8cdd7da7a2214dd062afff5b866234aab228), the bug still can reproduce. + +Please git fetch origin and try again. + + +The patch mentioned earlier has been committed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=625de449fc5597f2e1aff +... so I think we can mark this as fixed now. + diff --git a/results/classifier/118/graphic/1470 b/results/classifier/118/graphic/1470 new file mode 100644 index 000000000..7236f44eb --- /dev/null +++ b/results/classifier/118/graphic/1470 @@ -0,0 +1,39 @@ +graphic: 0.826 +boot: 0.802 +device: 0.688 +ppc: 0.632 +semantic: 0.564 +architecture: 0.510 +peripherals: 0.448 +arm: 0.431 +vnc: 0.393 +permissions: 0.326 +files: 0.319 +performance: 0.272 +PID: 0.253 +socket: 0.247 +debug: 0.211 +network: 0.193 +VMM: 0.185 +register: 0.177 +risc-v: 0.164 +user-level: 0.119 +mistranslation: 0.112 +TCG: 0.110 +virtual: 0.088 +kernel: 0.078 +hypervisor: 0.035 +x86: 0.033 +assembly: 0.031 +i386: 0.020 +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/118/graphic/1470720 b/results/classifier/118/graphic/1470720 new file mode 100644 index 000000000..92970c06d --- /dev/null +++ b/results/classifier/118/graphic/1470720 @@ -0,0 +1,83 @@ +graphic: 0.921 +hypervisor: 0.872 +performance: 0.792 +network: 0.704 +architecture: 0.606 +virtual: 0.585 +KVM: 0.531 +kernel: 0.517 +ppc: 0.507 +semantic: 0.500 +device: 0.498 +assembly: 0.480 +peripherals: 0.477 +debug: 0.462 +i386: 0.387 +x86: 0.380 +files: 0.366 +vnc: 0.354 +PID: 0.347 +register: 0.333 +user-level: 0.312 +mistranslation: 0.269 +socket: 0.267 +arm: 0.267 +risc-v: 0.238 +permissions: 0.209 +VMM: 0.195 +TCG: 0.162 +boot: 0.140 + +high IRQ-TLB generates network interruptions + + we are having a problem in our hosts, all the vm running on them suddenly, and for some seconds, lost network connectivity. + +the root cause appears to be the increase of irb-tlb from low values (less than 20) to more than >100k, that spike only last for some seconds then everything goes back to normal + +i've upload an screenshot of collectd for one hypervisor here +http://zumbi.com.ar/tmp/irq-tlb.png + + +we have hosts running precise (qemu 1.5, ovs 2.0.2, libvirt 1.2.2 and kernel 3.13) where the issue is frequent. also we have an small % of our fleet running trusty (qemu 2.0.0 ovs 2.0.2 libvirt 1.2.2 and kernel 3.16) where the problem seemed to be nonexistent until today + +issue seems to be isolated to < 10% of our hypervisors, some hypervisors had this problem every few days, others only once or twice. our vm are a black box to us we don't know what users run on them, but mostly cpu and network bound workload. +most of our guests run centos 6.5 (kernel 2.6.32) + +vm are bridged to a linuxbridge then veth wired to an ovs switch (neutron openvswitch agent setup) + + + +maybe first part is not clear, here it goes again + + this happens on some hypervisors at random times, not all hypervisors at the same time, and affects all vm on the hypervisor + +overcommit ratio on latest server i had the problem is 3.6 (3.6 vcpu for each cpu), would that be part of the problem? i see other servers that never had the problem with over commit ratios as high as 4.1 + +Seeing the same here, also happens on overbooked hypervisors. + +Just one or two hosts have this behaviour. + +We are using: +qemu-kvm 2.0.0+dfsg-2ubuntu1.25 +libvirt-bin 1.2.9 +kernel 3.13.0-92-generic + +We are using contrail as a SDN. + +It looks like it started after upgrading a bunch of packages including kernel (we came from 3.13.0-83-generic) + + +Disabling huge pages seem to help. +Strangely this should theoretically increase the issue but it so far we have not seen issues after disabling THP. +(have not seen high load spikes in a week but this might also be holiday related) + +So other people can try it out: +echo never >/sys/kernel/mm/transparent_hugepage/defrag +echo never > /sys/kernel/mm/transparent_hugepage/enabled + + + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1471 b/results/classifier/118/graphic/1471 new file mode 100644 index 000000000..b00643aa3 --- /dev/null +++ b/results/classifier/118/graphic/1471 @@ -0,0 +1,46 @@ +graphic: 0.967 +architecture: 0.921 +x86: 0.911 +device: 0.844 +network: 0.791 +semantic: 0.783 +PID: 0.731 +ppc: 0.703 +performance: 0.677 +socket: 0.669 +vnc: 0.600 +debug: 0.590 +arm: 0.473 +TCG: 0.455 +VMM: 0.436 +files: 0.427 +register: 0.419 +risc-v: 0.400 +permissions: 0.333 +mistranslation: 0.331 +boot: 0.296 +kernel: 0.237 +user-level: 0.163 +virtual: 0.133 +peripherals: 0.126 +hypervisor: 0.088 +assembly: 0.084 +i386: 0.079 +KVM: 0.028 + +16fc5726a6 breaks curl SSL connections +Description of problem: +`./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk` should work, just as `./qemu-aarch64 /path/to/curl-aarch64 https://news.bbc.co.uk` does. However, commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4 broke this (determined via `git bisect`). +Steps to reproduce: +1. Checkout and build `qemu` commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4 +2. On an aarch64 host system, download the amd64 build of `curl` from https://github.com/moparisthebest/static-curl/releases/tag/v7.87.0 +3. Run `./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk` +4. Observe the following error message: + +``` +curl: (35) error:1416D07B:SSL routines:tls_process_key_exchange:bad signature +``` + +Note that the `aarch64` equivalent works just fine. As does the previous commit using `amd64`. + +Also note, this bug is also present at current tip (13356edb87506c148b163b8c7eb0695647d00c2a). diff --git a/results/classifier/118/graphic/1474 b/results/classifier/118/graphic/1474 new file mode 100644 index 000000000..26eec8539 --- /dev/null +++ b/results/classifier/118/graphic/1474 @@ -0,0 +1,38 @@ +graphic: 0.978 +virtual: 0.877 +device: 0.851 +performance: 0.805 +VMM: 0.667 +risc-v: 0.617 +semantic: 0.596 +vnc: 0.566 +mistranslation: 0.564 +TCG: 0.474 +files: 0.463 +network: 0.463 +kernel: 0.439 +i386: 0.433 +x86: 0.394 +arm: 0.389 +KVM: 0.380 +architecture: 0.374 +PID: 0.348 +debug: 0.334 +user-level: 0.332 +ppc: 0.327 +socket: 0.318 +hypervisor: 0.282 +boot: 0.272 +register: 0.177 +peripherals: 0.127 +assembly: 0.080 +permissions: 0.017 + +qemu stuck at creating vm when enabling sgx feature +Description of problem: +After execute the command line, qemu stucked. + + + + +After the info in the png, qemu clear the screen and then nothing happend. diff --git a/results/classifier/118/graphic/1475 b/results/classifier/118/graphic/1475 new file mode 100644 index 000000000..c91d4f7d8 --- /dev/null +++ b/results/classifier/118/graphic/1475 @@ -0,0 +1,44 @@ +graphic: 0.928 +device: 0.913 +network: 0.853 +performance: 0.825 +socket: 0.802 +PID: 0.790 +files: 0.788 +arm: 0.690 +kernel: 0.666 +semantic: 0.645 +architecture: 0.632 +ppc: 0.611 +vnc: 0.533 +permissions: 0.525 +risc-v: 0.433 +TCG: 0.410 +peripherals: 0.395 +hypervisor: 0.391 +boot: 0.385 +mistranslation: 0.383 +register: 0.380 +VMM: 0.361 +debug: 0.332 +i386: 0.331 +x86: 0.270 +virtual: 0.212 +KVM: 0.195 +user-level: 0.176 +assembly: 0.123 + +qemu-img: GLib: g_hash_table_foreach_remove: assertion 'hash_table != NULL' failed +Description of problem: +Mixing driver=https with an http URL gives this assert fail in glib2: + +``` +$ ~/d/qemu/build/qemu-img convert -p -W -f qcow2 'json:{ "file.readahead": 67108864, "file.driver": "https", "file.url": "http://web/tmp/jammy-server-cloudimg-amd64.qcow2", "file.timeout":2000 }' -O raw jammy-server-cloudimg-amd64.img.raw +qemu-img: GLib: g_hash_table_foreach_remove: assertion 'hash_table != NULL' failed +qemu-img: GLib: g_hash_table_destroy: assertion 'hash_table != NULL' failed +qemu-img: Could not open 'json:{ "file.readahead": 67108864, "file.driver": "https", "file.url": "http://web/tmp/jammy-server-cloudimg-amd64.qcow2", "file.timeout":2000 }': https curl driver cannot handle the URL 'http://oirase.annexia.org/tmp/jammy-server-cloudimg-amd64.qcow2' (does not start with 'https://') +``` + +(It seems to be a warning rather than a crash) +Steps to reproduce: +1. Run the command above. diff --git a/results/classifier/118/graphic/1479632 b/results/classifier/118/graphic/1479632 new file mode 100644 index 000000000..7717992dc --- /dev/null +++ b/results/classifier/118/graphic/1479632 @@ -0,0 +1,101 @@ +i386: 0.984 +user-level: 0.957 +graphic: 0.954 +boot: 0.953 +mistranslation: 0.925 +device: 0.924 +x86: 0.904 +semantic: 0.894 +performance: 0.885 +PID: 0.833 +hypervisor: 0.817 +architecture: 0.811 +ppc: 0.799 +risc-v: 0.728 +socket: 0.720 +kernel: 0.708 +KVM: 0.702 +files: 0.699 +VMM: 0.698 +vnc: 0.689 +permissions: 0.684 +network: 0.680 +peripherals: 0.679 +debug: 0.675 +register: 0.647 +assembly: 0.628 +arm: 0.608 +TCG: 0.546 +virtual: 0.450 + +dos crashing no sound + +I use this command when I use sound in a program there is no sound and sometimes the program crashes or hangs with no mouse +working. I can though reset with the system with the control menu, but this is further hard to use, because there is no option to scroll through all the commands, I did not visited a wiki page yet. + +This is my command. + +qemu-system-i386 -soundhw all -m 1g -boot menu=on -hda dos622_1.img -boot d + +I have quite freed up some memory, but that didn't help. + +I used qemu because of a bug in dosbox, but that appeared to be the unclutter program and I have now uninstalled it. + +Not to mention that I did not knew that qemu is in such a beta phase. + +Regards, + +BCJ2014 + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Hello, I also am afraid thet in the image there is no sound driver, +maybe that's the problem. +And its so long ago that you can close it. + +2018-07-24 9:27 GMT+02:00, Thomas Huth <email address hidden>: +> Looking through old bug tickets... can you still reproduce this issue +> with the latest version of QEMU? Or could we close this ticket nowadays? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1479632 +> +> Title: +> dos crashing no sound +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> I use this command when I use sound in a program there is no sound and +> sometimes the program crashes or hangs with no mouse +> working. I can though reset with the system with the control menu, but +> this is further hard to use, because there is no option to scroll through +> all the commands, I did not visited a wiki page yet. +> +> This is my command. +> +> qemu-system-i386 -soundhw all -m 1g -boot menu=on -hda dos622_1.img +> -boot d +> +> I have quite freed up some memory, but that didn't help. +> +> I used qemu because of a bug in dosbox, but that appeared to be the +> unclutter program and I have now uninstalled it. +> +> Not to mention that I did not knew that qemu is in such a beta phase. +> +> Regards, +> +> BCJ2014 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1479632/+subscriptions +> + + diff --git a/results/classifier/118/graphic/1492649 b/results/classifier/118/graphic/1492649 new file mode 100644 index 000000000..3f7409040 --- /dev/null +++ b/results/classifier/118/graphic/1492649 @@ -0,0 +1,75 @@ +graphic: 0.978 +mistranslation: 0.947 +x86: 0.943 +architecture: 0.942 +kernel: 0.941 +device: 0.916 +performance: 0.899 +peripherals: 0.854 +user-level: 0.808 +semantic: 0.749 +ppc: 0.713 +assembly: 0.634 +PID: 0.625 +permissions: 0.624 +arm: 0.568 +hypervisor: 0.537 +vnc: 0.502 +register: 0.498 +debug: 0.492 +socket: 0.482 +network: 0.452 +virtual: 0.439 +boot: 0.419 +risc-v: 0.388 +files: 0.357 +i386: 0.349 +VMM: 0.329 +TCG: 0.198 +KVM: 0.159 + +QEMU soundhw HDA huge microphone lag + +I use a Windows 7 x86_64 guest with VGA passthrough and -soundhw hda. The audio plays fine, but the microphone input is delayed by more than 20 seconds. + +-soundhw ac97 does not have this delay but it has choppy sound playback and input. + +System: +Arch linux +Kernel: 4.1.6-1-ARCH +Audio hardware: 00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller +Audio system: Pulseaudio 6.0 + +I seem to have this issue too. Using latest 15.04 Ubuntu, qemu and -soundhw all. + +I can reproduce this on Windows 10 (64bit) with hda device. + +Host kernel is 4.1.13-rt15-1-rt, also tried with non-realtime kernel with same results. + +Output works without delay, given it is choppy from time to time. +Using the following env vars when starting QEMU: + +QEMU_AUDIO_DRV: pa +QEMU_PA_SAMPLE: 32 # also tried with 128, 256, 512 and 1024. Same results for input, output got less choppy but with notable latency +QEMU_PA_SERVER: unix:/run/user/1000/pulse/native # where user with uid is the user with Xorg and PA session, of course. + + + +I cannot figure out why - but, it would seem the input ringbuffer is not processed till the buffer is full. +As an ugly workaround, i tried to set the buffering attributes to the input section - which reduced the delay to less then a second. (important part here is ba.maxlength) + +I've got this issue too on windows 10 with QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-4). It seems to only occur when the device isn't used in the windows host for a while by any application. If an application opens the capture device, the delay slowly gets smaller until it's only a 4th of a second. + +My uneducated guess is that the pa/hda driver isn't dequeuing the buffer unless the device is opened and being used by an application. This should not be happening, it should move the read pointer to the sample length even if the device isn't being used. + +Proofread your comments, guys... oops + +So it's a debian HOST and windows GUEST, not windows host. :-l + +Sorry for the double post. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1493033 b/results/classifier/118/graphic/1493033 new file mode 100644 index 000000000..e9e19a58c --- /dev/null +++ b/results/classifier/118/graphic/1493033 @@ -0,0 +1,88 @@ +graphic: 0.877 +device: 0.704 +files: 0.685 +performance: 0.647 +network: 0.612 +vnc: 0.594 +ppc: 0.564 +socket: 0.558 +PID: 0.521 +architecture: 0.443 +permissions: 0.404 +semantic: 0.386 +virtual: 0.383 +hypervisor: 0.336 +i386: 0.319 +x86: 0.312 +register: 0.307 +user-level: 0.306 +boot: 0.304 +debug: 0.289 +kernel: 0.271 +peripherals: 0.266 +VMM: 0.249 +TCG: 0.247 +risc-v: 0.240 +arm: 0.235 +mistranslation: 0.209 +KVM: 0.148 +assembly: 0.114 + +memory leak/high memory usage with spice webdav feature + +This bug is being open due the comment: +https://bugs.freedesktop.org/show_bug.cgi?id=91350#c9 + +Description of problem: +When copying big files from client to guest, the memory usage in the host grows by about the size of the file. This is partially spice problem due the memory pool being able to increase as much as necessary without a limit which should be handled by the patches sent in the mailing list [0] + +[0] http://lists.freedesktop.org/archives/spice-devel/2015-August/021644.html + +At the same time, massif shows high memory usage by qemu as well [1] (output attached) + +[1] (peak) +->49.64% (267,580,319B) 0x308B89: malloc_and_trace (vl.c:2724) +| ->49.38% (266,167,561B) 0x67CE678: g_malloc (gmem.c:97) +| | ->49.03% (264,241,152B) 0x511D8E: qemu_coroutine_new (coroutine-ucontext.c:106) +| | | ->49.03% (264,241,152B) 0x510E24: qemu_coroutine_create (qemu-coroutine.c:74) +(...) + +The file being shared was a 320M ogv video. + +Version-Release number of selected component (if applicable): +QEMU emulator version 2.3.93 +SPICE and SPICE-GTK: from git master + +How reproducible: +100% + +Steps to Reproduce: +1-) build spice-gtk with --enable-webdav=yes +2-) enable webdav in your VM by following: +https://elmarco.fedorapeople.org/manual.html#_folder_sharing +3-) using remote-viewer with webdav patches, connects to a fedora guest +4-) Open nautilus, go to 'Browse Network' +5-) On remote-viewer, enable shared folder by File > Preferences > [X] Share folder +6-) The spice client folder should appear: Double-click to mount it. +7-) Check the memory of your qemu process +8-) Copy a big file (let's say, 300 MB) from the shared folder to local VM +9-) See the memory consumption of qemu grows by a lot; + +Actual results: +Memory usage grows during copy and is not freed + +Expected results: +Memory should have an upper limit to grow and should be freed after copy + +Additional info: +Also reported in Fedora/rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=1256376 +SPICE upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=91350 + + + +patches: http://lists.freedesktop.org/archives/spice-devel/2015-August/021644.html + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU and spice? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1496712 b/results/classifier/118/graphic/1496712 new file mode 100644 index 000000000..5dbeb2beb --- /dev/null +++ b/results/classifier/118/graphic/1496712 @@ -0,0 +1,72 @@ +graphic: 0.931 +peripherals: 0.882 +virtual: 0.881 +permissions: 0.845 +device: 0.839 +architecture: 0.834 +debug: 0.808 +PID: 0.808 +semantic: 0.776 +VMM: 0.767 +files: 0.766 +arm: 0.756 +user-level: 0.742 +performance: 0.733 +hypervisor: 0.720 +assembly: 0.714 +ppc: 0.708 +socket: 0.693 +kernel: 0.690 +mistranslation: 0.663 +boot: 0.658 +x86: 0.655 +network: 0.646 +KVM: 0.603 +TCG: 0.587 +vnc: 0.587 +register: 0.554 +risc-v: 0.497 +i386: 0.443 + +no bootable device after qemu-img convert parallels windows 2012 r2 to raw/qcow2 + +Hello +We have converted a parallels windows 2012 R2 image with the command +qemu-img convert -p -f parallels -O raw ./TestLibvirt.pvm/TestLibvirtMig-0.hdd/TestLibvirtMig-0.hdd.0.hds /var/lib/libvirt/images/testlibvirtmig.raw + +Afterthat we have created a new entry with virtual machine manager and used this raw-hdd file as "import existing disk image" + +Then we booted this virtual server and we got the error +"Booting from Hard Disk" +"no Bootable device" + +Test 1: we also tried to "overwrite" the windows server drive +1. Create a vm with windows 2012 r2 (W2K12R2) with virtual machine manager. Which runs good +2. Then we mounted in the command line the "no bootable device" server as source (raw image) + mount /ev/mapper/loop0p4 /mnt/source +3. Then we mounted the new created (W2K12R2) as target (raw image) + mount /ev/mapper/loop1p2 /mnt/target +4. with the copy command we have overwritten all files on the windows drive + rsync -av --delete /mnt/source/* /mnt/target/ +5. reboot the server and we have a blue screen and it tells me something prl_strg.sys + "your PC ran into a problem and needs to restart ...... If you'd like to know more, you can search online later for this error: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED(prl_strg.sys) + +Test 2: We also did a qemu-img convert from an ubuntu 14.04 disk and this works perfect. + +Thanks a lot +Moritz + +PS: Installation of Host-Server uses: ubuntu vivid 15.04 with +qemu-system 1:2.2+dfsg-5expubuntu9.4 +libvirt-bin 1.2.12-0ubuntu14.2 +libvirt-glib-1.0-0 0.1.9-4 +libvirt0 1.2.12-0ubuntu14.2 +virt-manager 1:1.0.1-5ubuntu1 + + + +Looking through old bug tickets... can you still reproduce this issue with the latest *upstream* version of QEMU? Or could we close this ticket nowadays? (or in case you want to get support for qemu-img from Ubuntu instead, please use the "qemu" Ubuntu package as target, not the "qemu" project target) + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1504513 b/results/classifier/118/graphic/1504513 new file mode 100644 index 000000000..1613cae26 --- /dev/null +++ b/results/classifier/118/graphic/1504513 @@ -0,0 +1,115 @@ +graphic: 0.902 +semantic: 0.898 +virtual: 0.896 +hypervisor: 0.889 +user-level: 0.888 +permissions: 0.882 +peripherals: 0.877 +mistranslation: 0.877 +performance: 0.870 +arm: 0.855 +assembly: 0.851 +risc-v: 0.850 +architecture: 0.848 +socket: 0.847 +register: 0.844 +device: 0.839 +debug: 0.835 +PID: 0.829 +kernel: 0.828 +ppc: 0.819 +boot: 0.815 +TCG: 0.810 +vnc: 0.803 +x86: 0.766 +KVM: 0.758 +network: 0.756 +VMM: 0.737 +files: 0.735 +i386: 0.559 + +Socket leak on each call to qemu_socket() + +On any host platform where SOCK_CLOEXEC is defined (Linux at least), a socket is leaked on each call to qemu_socket() AND the socket returned hasn't been created with the desired SOCK_CLOEXEC attribute. The qemu_socket routine is: + +Line 272 of util/osdep.c: +/* + * Opens a socket with FD_CLOEXEC set + */ +int qemu_socket(int domain, int type, int protocol) +{ + int ret; + +#ifdef SOCK_CLOEXEC + ret = socket(domain, type | SOCK_CLOEXEC, protocol); + if (ret != -1 || errno != EINVAL) { + return ret; + } +#endif + ret = socket(domain, type, protocol); + if (ret >= 0) { + qemu_set_cloexec(ret); + } + + return ret; +} + +I'm not sure that my original report was distributed to the folks who need to see this. My primary email address has a DKIM policy (DMARC) which says that all messages from my address are signed. I received various DMARC reports which said that the bug report sent as "From: <email address hidden>" were rejected. The bug report messages were reasonably sent with an SMTP envelope from of <email address hidden> and a "Sender: <email address hidden>". Hmm... Maybe 163.com is rewriting message headers. In any case, the message would have passed the DMARC check if my email address was in a "Reply-To: <email address hidden>" header (there was no Reply-To: header), and the "From:" header was a @nongnu.org address. + +I have changed my account to use my users.sourceforge.com forwarding address and I'm now generating this comment so that hopefully, the whole message will be widely distributed with a from address which doesn't have the same DMARC policy. + +On Sunday, October 11, 2015 at 11:58 PM. Markus Armbruster wrote: +> Mark Pizzolato <email address hidden> writes: +> +> > Public bug reported: +> > +> > On any host platform where SOCK_CLOEXEC is defined (Linux at least), a +> > socket is leaked on each call to qemu_socket() AND the socket returned +> > hasn't been created with the desired SOCK_CLOEXEC attribute. The +> > qemu_socket routine is: +> > +> > Line 272 of util/osdep.c: +> > /* +> > * Opens a socket with FD_CLOEXEC set +> > */ +> > int qemu_socket(int domain, int type, int protocol) +> > { +> > int ret; +> > +> > #ifdef SOCK_CLOEXEC +> > ret = socket(domain, type | SOCK_CLOEXEC, protocol); +> > if (ret != -1 || errno != EINVAL) { +> > return ret; +> +> If socket() succeeded (ret != -1), we return the socket. +> +> If socket() failed with anything but EINVAL (ret == -1 && errno != +> EINVAL), we return -1 with errno set. +> +> > } +> +> Here, ret == -1 && errno == EINVAL. +> +> > #endif +> > ret = socket(domain, type, protocol); +> > if (ret >= 0) { +> > qemu_set_cloexec(ret); +> > } +> > +> > return ret; +> > } +> +> How can this leak a socket? +> +> How can this return a socket with FD_CLOEXEC not set? + +All I can say is "OOPS!!" Sorry for bothering you. I misread the status check after the first socket() call. + +I'm in the process of lifting qemu's slirp code and dropping it into another open source project. Since I'm trying to use all the code in the slirp directory without modification I'm digging through where it now depends on other qemu code. I quickly looked at the qemu_socket() routine and read it wrong. + +Once again, sorry. + +- Mark Pizzolato + + + diff --git a/results/classifier/118/graphic/1508 b/results/classifier/118/graphic/1508 new file mode 100644 index 000000000..ba99a902f --- /dev/null +++ b/results/classifier/118/graphic/1508 @@ -0,0 +1,121 @@ +graphic: 0.877 +permissions: 0.858 +semantic: 0.849 +debug: 0.842 +user-level: 0.841 +register: 0.840 +virtual: 0.831 +device: 0.795 +performance: 0.785 +peripherals: 0.763 +hypervisor: 0.763 +mistranslation: 0.753 +x86: 0.751 +boot: 0.746 +network: 0.742 +architecture: 0.738 +assembly: 0.724 +risc-v: 0.720 +PID: 0.712 +vnc: 0.710 +VMM: 0.702 +files: 0.696 +KVM: 0.687 +arm: 0.679 +kernel: 0.668 +socket: 0.665 +TCG: 0.637 +i386: 0.604 +ppc: 0.581 + +vfio-pci 0000:00:02.1: VF token required to access device +Description of problem: +I'm trying to use SR-IOV on an i5-12400 trying to create VFs for my UHD Graphics 730. + +I had to build this DKMS module for it to work: +https://github.com/strongtz/i915-sriov-dkms + +So far I have managed to have 7 VFs created per the dmsg: +``` +[root@fedora ~]# dmesg | grep -i vf +[ 0.000000] Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.1.13-200.fc37.x86_64 root=UUID=a1ec5891-71c6-44ea-9beb-c4f1cde55c0e ro rootflags=subvol=root rhgb quiet intel_iommu=on iommu=pt split_lock_detect=off i915.enable_guc=7 video=vesafb:off video=efifb:off initcall_blacklist=sysfb_init vfio-pci.disable_vga=1 vfio-pci.enable_sriov=1 vfio-pci.ids=8086:4692,8086:7ad0 +[ 0.074362] Kernel command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.1.13-200.fc37.x86_64 root=UUID=a1ec5891-71c6-44ea-9beb-c4f1cde55c0e ro rootflags=subvol=root rhgb quiet intel_iommu=on iommu=pt split_lock_detect=off i915.enable_guc=7 video=vesafb:off video=efifb:off initcall_blacklist=sysfb_init v +io-pci.disable_vga=1 vfio-pci.enable_sriov=1 vfio-pci.ids=8086:4692,8086:7ad0 +[ 0.288336] pci 0000:00:02.0: VF(n) BAR0 space: [mem 0x60e0000000-0x60e6ffffff 64bit] (contains BAR0 for 7 VFs) +[ 0.288339] pci 0000:00:02.0: VF(n) BAR2 space: [mem 0x6000000000-0x60dfffffff 64bit pref] (contains BAR2 for 7 VFs) +[ 0.293518] pci 0000:01:00.0: VF(n) BAR0 space: [mem 0xa1330000-0xa134ffff 64bit] (contains BAR0 for 8 VFs) +[ 0.336464] VFS: Disk quotas dquot_6.6.0 +[ 0.336470] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) +[ 1.028560] VFIO - User Level meta-driver version: 0.3 +[ 1.039931] vfio-pci 0000:00:02.0: vgaarb: deactivate vga console +[ 1.039933] vfio-pci 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem +[ 1.040007] vfio_pci: add [8086:4692[ffffffff:ffffffff]] class 0x000000/00000000 +[ 1.040140] vfio_pci: add [8086:7ad0[ffffffff:ffffffff]] class 0x000000/00000000 +[ 3.373977] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 655360 ms ovfl timer +[ 45.696323] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.1 driver_override +[ 45.696356] vfio-pci 0000:00:02.1: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +[ 45.696598] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.2 driver_override +[ 45.696609] vfio-pci 0000:00:02.2: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +[ 45.696724] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.3 driver_override +[ 45.696734] vfio-pci 0000:00:02.3: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +[ 45.696811] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.4 driver_override +[ 45.696825] vfio-pci 0000:00:02.4: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +[ 45.696947] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.5 driver_override +[ 45.696958] vfio-pci 0000:00:02.5: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +[ 45.697050] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.6 driver_override +[ 45.697060] vfio-pci 0000:00:02.6: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +[ 45.697127] vfio-pci 0000:00:02.0: Captured SR-IOV VF 0000:00:02.7 driver_override +[ 45.697137] vfio-pci 0000:00:02.7: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +``` +I've blacklisted these modules: +``` +blacklist igb +blacklist i915 +blacklist snd_hda_intel +blacklist snd_sof_pci_intel_tgl +``` +And loaded these modules: +``` +vfio +vfio-pci +vfio_virqfd +vfio_iommu_type1 +``` +Kernel args: +``` +GRUB_CMDLINE_LINUX="rhgb quiet intel_iommu=on iommu=pt split_lock_detect=off i915.enable_guc=7 video=vesafb:off video=efifb:off initcall_blacklist=sysfb_init vfio-pci.disable_vga=1 vfio-pci.enable_sriov=1 vfio-pci.ids=8086:4692,8086:7ad0" +``` + +**Error shown:** +``` +[root@fedora ~]# ./test.sh +QEMU 7.0.0 monitor - type 'help' for more information +(qemu) qemu-system-x86_64: -device vfio-pci,host=0000:02.2,multifunction=on,bus=pcie.1,addr=0x00,x-vga=on: vfio 0000:00:02.2: error getting device from group 14: Permission denied +Verify all devices in group 14 are bound to vfio-<bus> or pci-stub and not already in use +``` +**DMESG shows:** +``` +[ 2160.408395] vfio-pci 0000:00:02.2: VF token required to access device +``` + +This lead me to this conversation / thread: + +https://inbox.dpdk.org/dev/CALBAE1MrEoCc8Ch6MNUNTsOcZyJnhr+z+iD0VWjHagQsEdBWCw@mail.gmail.com/#t + +Quote: "Something needs to be sorted with the QEMU community." + +In fact, something needs to be sorted. **It seems there's no way to specify this VF token anywhere from the CLI args**, so I'm reporting this as a bug (or feature not developed yet?? any ETA?) + +**Additional information:** It seems that QEMU might require a patch or a change to allow this VF token to be passed through. It seems that DPDK and other similar projects have already implemented this (it seems Linux has it since Kernel 5.7 - Maybe I'm missing something to pass this token with QEMU considering how old that kernel is? I'd expect this flag to be here in QEMU already) + +**Useful code / info:** +* https://patches.dpdk.org/project/dpdk/patch/20200529013710.72302-3-haiyue.wang@intel.com/ +* https://github.com/intel/pf-bb-config/blob/master/README.md#usage-example +* https://support.hpe.com/hpesc/public/docDisplay?docId=sd00001790en_us&docLocale=en_US&page=GUID-1D5D76F8-522A-47F5-922B-142BD5177033.html + +Thanks, + +-Alemar +Steps to reproduce: +1. See description +2. Run QEMU as described diff --git a/results/classifier/118/graphic/1508405 b/results/classifier/118/graphic/1508405 new file mode 100644 index 000000000..f130de923 --- /dev/null +++ b/results/classifier/118/graphic/1508405 @@ -0,0 +1,155 @@ +graphic: 0.891 +VMM: 0.883 +user-level: 0.866 +hypervisor: 0.863 +peripherals: 0.858 +TCG: 0.843 +KVM: 0.842 +mistranslation: 0.839 +ppc: 0.837 +performance: 0.837 +device: 0.835 +vnc: 0.831 +permissions: 0.830 +register: 0.830 +virtual: 0.828 +x86: 0.824 +assembly: 0.818 +arm: 0.802 +PID: 0.802 +debug: 0.799 +network: 0.792 +files: 0.787 +semantic: 0.778 +architecture: 0.776 +socket: 0.771 +kernel: 0.769 +risc-v: 0.753 +i386: 0.681 +boot: 0.677 + +qemu 2.4.0 with --enable-kvm hangs, takes 100% CPU + +When starting qemu-system-x86_64 from version 2.4.0 with --enable-kvm, it hangs and takes 100% CPU. The graphical display (SeaBIOS output) is not initialized. + +There have been multiple reports of this issue in the following thread: +https://bbs.archlinux.org/viewtopic.php?pid=1572405 + +There is no need to load a certain image, it already hangs with the following command: +qemu-system-x86_64 --enable-kvm + +There are three workarounds: +- Downgrading the kernel form 4.2.2 to 4.1.6 (according to the forum thread, have not tested this myself) +- Downgrading qemu to 2.3 (tested personally, works) +- passing -machine pc-i440fx-2.3 to qemu 2.4 (have not tested this myself, I will try that shortly) + +modules kvm and kvm_intel are loaded and rmmod && modprobing them does not change the situation + +I have an nvidia card and switching from official binary drivers to nouveau and back does not change the situation. + + +qemu is installed from Arch package. From the PKGBUILD you can see that is is built with the following configuration: +================================================================ +export ARFLAGS="rv" + export CFLAGS+=' -fPIC' + ./configure --prefix=/usr --sysconfdir=/etc --audio-drv-list='pa alsa sdl' \ + --python=/usr/bin/python2 --smbd=/usr/bin/smbd \ + --enable-docs --libexecdir=/usr/lib/qemu \ + --disable-gtk --enable-linux-aio --enable-seccomp \ + --enable-spice --localstatedir=/var \ + --enable-tpm \ + --enable-modules --enable-{rbd,glusterfs,libiscsi,curl} + make V=99 +================================================================ + +cpuinfo on my machine (for the first core only): + +================================================================ +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 30 +model name : Intel(R) Core(TM) i7 CPU Q 820 @ 1.73GHz +stepping : 5 +microcode : 0x7 +cpu MHz : 1333.000 +cache size : 8192 KB +physical id : 0 +siblings : 8 +core id : 0 +cpu cores : 4 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 11 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid +bugs : +bogomips : 3459.21 +clflush size : 64 +cache_alignment : 64 +address sizes : 36 bits physical, 48 bits virtual +================================================================ + +Is there more information I can provide you with to help debug this problem? + +Thanks, + +cptG + +Just confirmed: passing -machine pc-i440fx-2.3 to qemu 2.4 works on my machine, too. + +I guess I forgot about it before: Kernel version is 4.2.3 + +OK, I just git-bisected and it found the following commit to probably cause the problem: +===================== SNIP ======================================== +355023f2010c4df619d88a0dd7012b4b9c74c12c is the first bad commit +commit 355023f2010c4df619d88a0dd7012b4b9c74c12c +Author: Paolo Bonzini <email address hidden> +Date: Thu Jun 18 18:30:52 2015 +0200 + + pc: add SMM property + + The property can take values on, off or auto. The default is "off" + for KVM and pre-2.4 machines, otherwise "auto" (which makes it + available on TCG or on new-enough kernels). + + Acked-by: Michael S. Tsirkin <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> + +:040000 040000 28b1de64871e1baa3aaad155f22f7c44d5fdc94f 77265bdd62664d15d8ad6ef3364aeb284d030486 M hw +:040000 040000 8b933a2739a2dccb0b5e28ab3ce20e2bb703780b a8d444cb27fbd54b0b9a7bd9997db355da15763e M include +:040000 040000 1acb81aecaf50f2d313b33f2b61a24f7f0bd6f07 726899e7ae70d04dd9acd7000fa1c5dee715da3e M target-i386 +===================== SNIP ======================================== + + +The script I ran after each bisection step: + +===================== SNIP ======================================== +make clean +PREFIX=$PWD/localinstall +export ARFLAGS="rv" + # http://permalink.gmane.org/gmane.comp.emulators.qemu/238740 + export CFLAGS+=' -fPIC' + # gtk gui breaks keymappings at the moment + ./configure --prefix=$PREFIX --sysconfdir=/etc --audio-drv-list='pa alsa sdl' \ + --python=/usr/bin/python2 --smbd=/usr/bin/smbd \ + --enable-docs --libexecdir=$PREFIX/lib/qemu \ + --disable-gtk --enable-linux-aio --enable-seccomp \ + --enable-spice --localstatedir=/var \ + --enable-tpm \ + --enable-modules --enable-{rbd,glusterfs,libiscsi,curl} + make V=99 -j9 && ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm +===================== SNIP ======================================== + + +Hope this helps! + + +Duh, I should've actually taken a closer look at the commit I found... another workaround for the problem is: + +qemu-system-x86_64 --enable-kvm -machine smm=off + +though the commit message seems to state that the default is off for kvm - so that's where the bug is? + diff --git a/results/classifier/118/graphic/1518 b/results/classifier/118/graphic/1518 new file mode 100644 index 000000000..0ba82f786 --- /dev/null +++ b/results/classifier/118/graphic/1518 @@ -0,0 +1,120 @@ +graphic: 0.829 +user-level: 0.781 +permissions: 0.780 +virtual: 0.734 +performance: 0.722 +debug: 0.694 +register: 0.687 +device: 0.677 +architecture: 0.672 +TCG: 0.667 +files: 0.658 +KVM: 0.645 +assembly: 0.617 +network: 0.611 +semantic: 0.599 +hypervisor: 0.572 +arm: 0.566 +PID: 0.557 +vnc: 0.553 +x86: 0.545 +risc-v: 0.520 +ppc: 0.515 +mistranslation: 0.506 +boot: 0.501 +kernel: 0.493 +socket: 0.484 +VMM: 0.468 +peripherals: 0.459 +i386: 0.411 + +qemu tests/unit/test-vmstate crashes in g_tree_foreach +Description of problem: +qemu test suite crashes with the latest Fedora Rawhide. +Downstream issue: https://bugzilla.redhat.com/show_bug.cgi?id=2173639 +Steps to reproduce: +1. Compile and test qemu from source as normal. + +``` +214/658 qemu:unit / test-vmstate ERROR 0.22s killed by signal 11 SIGSEGV +317/658 qemu:qtest+qtest-i386 / qtest-i386/rtl8139-test ERROR 0.28s 2 subtests passed +588/658 qemu:qtest+qtest-x86_64 / qtest-x86_64/rtl8139-test ERROR 0.45s 2 subtests passed +``` + +The stack trace from the test is: + +``` +#0 g_tree_foreach (user_data=0x7fffa23ccbc0, func=0x55a834fe3770 <diff_tree>, + tree=<optimized out>) at ../glib/gtree.c:1132 +#1 g_tree_foreach (tree=<optimized out>, func=0x55a834fe3770 <diff_tree>, + user_data=0x7fffa23ccbc0) at ../glib/gtree.c:1117 +#2 0x000055a834fe382c in compare_trees (tree1=0x55a836723bf0, + tree2=0x55a836723f50, + function=function@entry=0x55a834fe3570 <match_interval_mapping_node>) + at ../tests/unit/test-vmstate.c:1085 +#3 0x000055a834fee265 in diff_domain (d2=0x55a836709310, d1=0x55a836708fd0) + at ../tests/unit/test-vmstate.c:1093 +#4 test_gtree_load_domain () at ../tests/unit/test-vmstate.c:1138 +#5 0x00007f0eef39d32e in test_case_run (tc=0x55a836724150) + at ../glib/gtestutils.c:3108 +#6 g_test_run_suite_internal (suite=suite@entry=0x55a8367056e0, + path=path@entry=0x0) at ../glib/gtestutils.c:3203 +#7 0x00007f0eef39cf03 in g_test_run_suite_internal ( + suite=suite@entry=0x55a836705090, path=path@entry=0x0) + at ../glib/gtestutils.c:3222 +#8 0x00007f0eef39cf03 in g_test_run_suite_internal ( + suite=suite@entry=0x55a8366ff670, path=path@entry=0x0) + at ../glib/gtestutils.c:3222 +#9 0x00007f0eef39cf03 in g_test_run_suite_internal ( + suite=suite@entry=0x55a836700140, path=path@entry=0x0) +#10 0x00007f0eef39d8c2 in g_test_run_suite (suite=0x55a836700140) + at ../glib/gtestutils.c:3302 +#11 0x00007f0eef397c40 in g_test_run () at ../glib/gtestutils.c:2409 +#12 g_test_run () at ../glib/gtestutils.c:2396 +#13 0x000055a834fe2645 in main (argc=<optimized out>, argv=<optimized out>) + at ../tests/unit/test-vmstate.c:1523 +``` + +This can also be reproduced in gdb using a command similar to: + +``` +$ MALLOC_PERTURB_=175 G_TEST_SRCDIR=/home/rjones/d/qemu/tests/unit G_TEST_BUILDDIR=/home/rjones/d/qemu/build/tests/unit gdb --args /home/rjones/d/qemu/build/tests/unit/test-vmstate --tap -k +... +(gdb) run +Thread 1 "test-vmstate" received signal SIGSEGV, Segmentation fault. +g_tree_foreach (user_data=0x7fffffffd3e0, func=0x555555568770 <diff_tree>, tree=<optimized out>) at ../glib/gtree.c:1132 +1132 if ((*func) (node->key, node->value, user_data)) +(gdb) bt +#0 g_tree_foreach (user_data=0x7fffffffd3e0, func=0x555555568770 <diff_tree>, + tree=<optimized out>) at ../glib/gtree.c:1132 +#1 g_tree_foreach (tree=<optimized out>, func=0x555555568770 <diff_tree>, + user_data=0x7fffffffd3e0) at ../glib/gtree.c:1117 +#2 0x000055555556882c in compare_trees (tree1=0x5555555ccdb0, + tree2=0x5555555cd110, + function=function@entry=0x555555568570 <match_interval_mapping_node>) + at ../tests/unit/test-vmstate.c:1085 +#3 0x0000555555573265 in diff_domain (d2=0x5555555b3310, d1=0x5555555b2fd0) + at ../tests/unit/test-vmstate.c:1093 +#4 test_gtree_load_domain () at ../tests/unit/test-vmstate.c:1138 +#5 0x00007ffff7eb132e in test_case_run (tc=0x5555555cd310) + at ../glib/gtestutils.c:3108 +#6 g_test_run_suite_internal (suite=suite@entry=0x5555555af6e0, + path=path@entry=0x0) at ../glib/gtestutils.c:3203 +#7 0x00007ffff7eb0f03 in g_test_run_suite_internal ( + suite=suite@entry=0x5555555af090, path=path@entry=0x0) + at ../glib/gtestutils.c:3222 +#8 0x00007ffff7eb0f03 in g_test_run_suite_internal ( + suite=suite@entry=0x5555555a9670, path=path@entry=0x0) + at ../glib/gtestutils.c:3222 +#9 0x00007ffff7eb0f03 in g_test_run_suite_internal ( + suite=suite@entry=0x5555555aa140, path=path@entry=0x0) + at ../glib/gtestutils.c:3222 +#10 0x00007ffff7eb18c2 in g_test_run_suite (suite=0x5555555aa140) + at ../glib/gtestutils.c:3302 +#11 0x00007ffff7eabc40 in g_test_run () at ../glib/gtestutils.c:2409 +#12 g_test_run () at ../glib/gtestutils.c:2396 +#13 0x0000555555567645 in main (argc=<optimized out>, argv=<optimized out>) + at ../tests/unit/test-vmstate.c:1523 +``` + +Unfortunately so much is "optimized out" that it's hard to tell what's going wrong. diff --git a/results/classifier/118/graphic/1520730 b/results/classifier/118/graphic/1520730 new file mode 100644 index 000000000..6de5c86be --- /dev/null +++ b/results/classifier/118/graphic/1520730 @@ -0,0 +1,52 @@ +graphic: 0.843 +i386: 0.751 +user-level: 0.719 +device: 0.622 +mistranslation: 0.603 +semantic: 0.483 +performance: 0.479 +architecture: 0.409 +permissions: 0.285 +register: 0.209 +arm: 0.201 +x86: 0.199 +ppc: 0.192 +PID: 0.187 +network: 0.169 +debug: 0.168 +virtual: 0.133 +vnc: 0.132 +VMM: 0.121 +boot: 0.117 +files: 0.112 +socket: 0.109 +risc-v: 0.107 +peripherals: 0.102 +hypervisor: 0.069 +TCG: 0.038 +assembly: 0.035 +kernel: 0.032 +KVM: 0.014 + +32-bit editors vim/rhide broken keyboard handling in freedos 1.1 and ms-dos 6.22 + +This bug is present as of the latest commit: 714487515dbe0c65d5904251e796cd3a5b3579fb + +I also saw it in 2.4.1, but that was a distro package. + +You can see the bug simply using the following line: qemu-system-i386 -hda freedos.disk + +Simply type vim (or rhide) and start entering in some text. You'll notice repeating characters, and also eventually the key mode will change as if you're holding down the shift button. Not capslock. "a" will become "A", but "\" will also become "|". + +I don't think this is a bug in freedos because I get the same behavior with dos 6.22. Not dosbox, though. + + + +I'm seeing this issue in version 2.12.0-rc4. I wasn't seeing this as much in earlier 2.11, but its a major pain in the current version. + +Which user interface is this? + +Can you still reproduce this issue with the latest version of QEMU? Are you using a SDL or GTK build for the graphical interface? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1529859 b/results/classifier/118/graphic/1529859 new file mode 100644 index 000000000..135876f44 --- /dev/null +++ b/results/classifier/118/graphic/1529859 @@ -0,0 +1,227 @@ +graphic: 0.825 +assembly: 0.818 +architecture: 0.812 +socket: 0.802 +performance: 0.802 +permissions: 0.797 +arm: 0.795 +register: 0.792 +risc-v: 0.790 +debug: 0.788 +PID: 0.785 +kernel: 0.770 +semantic: 0.768 +virtual: 0.765 +network: 0.753 +files: 0.751 +boot: 0.743 +device: 0.738 +user-level: 0.735 +peripherals: 0.687 +hypervisor: 0.686 +mistranslation: 0.657 +ppc: 0.652 +KVM: 0.589 +TCG: 0.557 +VMM: 0.556 +vnc: 0.553 +x86: 0.514 +i386: 0.464 + +qemu 2.5.0 ivshmem segfault with msi=off option + +Launching qemu with "-device ivshmem,chardev=ivshmemid,msi=off -chardev socket,path=/tmp/ivshmem_socket,id=ivshmemid" + +Causes segfault because, s->msi_vectors is not initialized and s->msi_vectors == 0. + +Does ivshmem exactly need this line ? : + +s->msi_vectors[vector].pdev = pdev; + +It makes no sence for me. + +Subject: [PATCH] fixed ivshmem empty msi vector on msi=off segfault + +--- + hw/misc/ivshmem.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c +index f73f0c2..2087d5e 100644 +--- a/hw/misc/ivshmem.c ++++ b/hw/misc/ivshmem.c +@@ -359,8 +359,6 @@ static CharDriverState* create_eventfd_chr_device(void * opaque, EventNotifier * + int eventfd = event_notifier_get_fd(n); + CharDriverState *chr; + +- s->msi_vectors[vector].pdev = pdev; +- + chr = qemu_chr_open_eventfd(eventfd); + + if (chr == NULL) { +@@ -1038,10 +1036,11 @@ static void pci_ivshmem_exit(PCIDevice *dev) + } + + if (ivshmem_has_feature(s, IVSHMEM_MSI)) { +- msix_uninit_exclusive_bar(dev); ++ msix_uninit_exclusive_bar(dev); + } +- +- g_free(s->msi_vectors); ++ ++ if(s->msi_vectors) ++ g_free(s->msi_vectors); + } + + static bool test_msix(void *opaque, int version_id) +-- +2.3.6 + +On 12/29/2015 06:38 AM, maquefel wrote: +> Public bug reported: +> +> Launching qemu with "-device ivshmem,chardev=ivshmemid,msi=off -chardev +> socket,path=/tmp/ivshmem_socket,id=ivshmemid" +> +> Causes segfault because, s->msi_vectors is not initialized and +> s->msi_vectors == 0. +> +> Does ivshmem exactly need this line ? : +> +> s->msi_vectors[vector].pdev = pdev; +> +> It makes no sence for me. +> +> Subject: [PATCH] fixed ivshmem empty msi vector on msi=off segfault + +Patches require a Signed-off-by: line before they can be applied. + +> +> --- +> hw/misc/ivshmem.c | 9 ++++----- +> 1 file changed, 4 insertions(+), 5 deletions(-) +> +> diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c +> index f73f0c2..2087d5e 100644 +> --- a/hw/misc/ivshmem.c +> +++ b/hw/misc/ivshmem.c +> @@ -359,8 +359,6 @@ static CharDriverState* create_eventfd_chr_device(void * opaque, EventNotifier * +> int eventfd = event_notifier_get_fd(n); +> CharDriverState *chr; +> +> - s->msi_vectors[vector].pdev = pdev; +> - + +This avoids the segfault, but it may break other uses. Are you sure you +don't need an 'if (s->msi_vectors[vector])' conditional? + +> chr = qemu_chr_open_eventfd(eventfd); +> +> if (chr == NULL) { +> @@ -1038,10 +1036,11 @@ static void pci_ivshmem_exit(PCIDevice *dev) +> } +> +> if (ivshmem_has_feature(s, IVSHMEM_MSI)) { +> - msix_uninit_exclusive_bar(dev); +> + msix_uninit_exclusive_bar(dev); + +I can't see what's changing here. Whitespace? + +> } +> - +> - g_free(s->msi_vectors); +> + +> + if(s->msi_vectors) +> + g_free(s->msi_vectors); + +This hunk is bogus. g_free(NULL) already works properly. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +See previously posted patch: + +http://lists.gnu.org/archive/html/qemu-stable/2015-12/msg00034.html + +On Mon, Jan 4, 2016 at 9:24 PM, Eric Blake <email address hidden> wrote: +> On 12/29/2015 06:38 AM, maquefel wrote: +>> Public bug reported: +>> +>> Launching qemu with "-device ivshmem,chardev=ivshmemid,msi=off -chardev +>> socket,path=/tmp/ivshmem_socket,id=ivshmemid" +>> +>> Causes segfault because, s->msi_vectors is not initialized and +>> s->msi_vectors == 0. +>> +>> Does ivshmem exactly need this line ? : +>> +>> s->msi_vectors[vector].pdev = pdev; +>> +>> It makes no sence for me. +>> +>> Subject: [PATCH] fixed ivshmem empty msi vector on msi=off segfault +> +> Patches require a Signed-off-by: line before they can be applied. +> +>> +>> --- +>> hw/misc/ivshmem.c | 9 ++++----- +>> 1 file changed, 4 insertions(+), 5 deletions(-) +>> +>> diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c +>> index f73f0c2..2087d5e 100644 +>> --- a/hw/misc/ivshmem.c +>> +++ b/hw/misc/ivshmem.c +>> @@ -359,8 +359,6 @@ static CharDriverState* create_eventfd_chr_device(void * opaque, EventNotifier * +>> int eventfd = event_notifier_get_fd(n); +>> CharDriverState *chr; +>> +>> - s->msi_vectors[vector].pdev = pdev; +>> - +> +> This avoids the segfault, but it may break other uses. Are you sure you +> don't need an 'if (s->msi_vectors[vector])' conditional? +> +>> chr = qemu_chr_open_eventfd(eventfd); +>> +>> if (chr == NULL) { +>> @@ -1038,10 +1036,11 @@ static void pci_ivshmem_exit(PCIDevice *dev) +>> } +>> +>> if (ivshmem_has_feature(s, IVSHMEM_MSI)) { +>> - msix_uninit_exclusive_bar(dev); +>> + msix_uninit_exclusive_bar(dev); +> +> I can't see what's changing here. Whitespace? +> +>> } +>> - +>> - g_free(s->msi_vectors); +>> + +>> + if(s->msi_vectors) +>> + g_free(s->msi_vectors); +> +> This hunk is bogus. g_free(NULL) already works properly. +> +> -- +> Eric Blake eblake redhat com +1-919-301-3266 +> Libvirt virtualization library http://libvirt.org +> + + + +-- +Marc-André Lureau + + +>See previously posted patch: +> http://lists.gnu.org/archive/html/qemu-stable/2015-12/msg00034.html + +This patch resolves issue. I can confirm it works. + +Patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=47213eb1104709bf23 + diff --git a/results/classifier/118/graphic/1530 b/results/classifier/118/graphic/1530 new file mode 100644 index 000000000..c1747c1cc --- /dev/null +++ b/results/classifier/118/graphic/1530 @@ -0,0 +1,41 @@ +graphic: 0.931 +device: 0.879 +performance: 0.744 +peripherals: 0.585 +debug: 0.529 +architecture: 0.520 +semantic: 0.479 +PID: 0.398 +permissions: 0.310 +risc-v: 0.290 +ppc: 0.289 +register: 0.281 +mistranslation: 0.269 +arm: 0.250 +user-level: 0.246 +boot: 0.218 +i386: 0.204 +TCG: 0.175 +virtual: 0.152 +socket: 0.101 +x86: 0.098 +vnc: 0.087 +files: 0.083 +hypervisor: 0.077 +VMM: 0.068 +kernel: 0.039 +network: 0.038 +assembly: 0.020 +KVM: 0.006 + +Problem with sdl,gl=on windows 10 +Description of problem: +sdl window opens with black screen, freezes, then crashes +Steps to reproduce: +1. run the command +Additional information: +- Works fine with just `sdl`, running `gtk,gl=on` outputs `opengl is not supported by the display` +- tried with both `-vga virtio` and `vga std`, same result +- tried with SVM turned on and off (AMD cpu, ryzen 2600x), same result +- built the project `./configure --enable-gtk --enable-sdl --enable-opengl, saw the `OK` for all 3 +- have opengl ver 4.6 diff --git a/results/classifier/118/graphic/1530035 b/results/classifier/118/graphic/1530035 new file mode 100644 index 000000000..dd87541db --- /dev/null +++ b/results/classifier/118/graphic/1530035 @@ -0,0 +1,59 @@ +graphic: 0.891 +device: 0.887 +x86: 0.882 +PID: 0.869 +user-level: 0.844 +peripherals: 0.824 +performance: 0.793 +semantic: 0.785 +architecture: 0.778 +files: 0.769 +network: 0.750 +ppc: 0.749 +kernel: 0.713 +socket: 0.696 +mistranslation: 0.690 +KVM: 0.686 +permissions: 0.680 +i386: 0.680 +debug: 0.671 +hypervisor: 0.662 +register: 0.656 +vnc: 0.636 +VMM: 0.628 +boot: 0.622 +risc-v: 0.559 +TCG: 0.546 +assembly: 0.519 +arm: 0.499 +virtual: 0.479 + +usb-host: ATI Technologies, Inc. TV Wonder acts as a different device if used + +Title says it all. If you try to use the "ATI Technologies, Inc. TV Wonder" USB 1.1 TV Tuner for passthrough under any OS that has drivers for the device, the usb-host driver will confuse itself and give the device a new PID number for Linux. + +Tested on ReactOS and Windows XP with stable QEMU package from pacman on Arch Linux. + +Commands used: sudo qemu-system-x86_64 -enable-kvm -hda ~/QEMU/hd/winxp.img -usb -device usb-host,hostbus=2,hostaddr=3 -vga vmware + +Before starting qemu-kvm, lsusb reports: +[ +Bus 002 Device 003: ID 0528:7561 ATI Technologies, Inc. TV Wonder +] + +After starting qemu-kvm, usb-host and lsusb report: +[ +libusb: error [_get_usbfs_fd] File doesn't exist, wait 10 ms and try again +libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/003: No such file or directory + +The device in Bus 2, Device 3 is gone and it appears as this instead: +Bus 002 Device 005: ID 0573:0400 Zoran Co. Personal Media Division (Nogatech) D-Link V100 +] + +This weird effect only lasts until you unplug the TV Wonder. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1530278 b/results/classifier/118/graphic/1530278 new file mode 100644 index 000000000..b14c3d6d0 --- /dev/null +++ b/results/classifier/118/graphic/1530278 @@ -0,0 +1,48 @@ +graphic: 0.892 +virtual: 0.883 +x86: 0.877 +socket: 0.834 +i386: 0.815 +boot: 0.812 +network: 0.808 +device: 0.802 +user-level: 0.767 +architecture: 0.730 +semantic: 0.726 +hypervisor: 0.720 +peripherals: 0.717 +mistranslation: 0.706 +permissions: 0.703 +kernel: 0.697 +performance: 0.694 +vnc: 0.676 +KVM: 0.650 +PID: 0.635 +files: 0.612 +debug: 0.596 +assembly: 0.582 +register: 0.563 +ppc: 0.562 +VMM: 0.479 +arm: 0.410 +risc-v: 0.385 +TCG: 0.314 + +vhost-user: can not detach chardev which is used by vhost-user backend + +I launch a VM which use vhost-user netdevice as follows.When detach the netdevice in qemu monitor, the chardevice which used by the netdevice also should be deatched.The netdevice can be detached sucessfully.But the chardevice failed when it was being detaching. +Full command line : +qemu-system-x86_64 \ +-cpu host -boot c -hda /home/lining/ubuntu_12_04.img -snapshot -m 2048 -smp 2 \ +--enable-kvm -name "client1" -vnc :1 \ +-object memory-backend-file,id=mem,size=2048M,mem-path=/dev/hugepages,share=on -numa node,memdev=mem \ +-chardev socket,id=chr1,path=/opt/network/ovdk/bin/vhost-user \ +-netdev vhost-user,id=net12,chardev=chr1,ifname=port80, vhostforce \ +-device virtio-net-pci,netdev=net12,mac=00:00:00:00:00:01,\ +csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off,guest_ufo=off,any_layout=off + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1530386 b/results/classifier/118/graphic/1530386 new file mode 100644 index 000000000..15a5745aa --- /dev/null +++ b/results/classifier/118/graphic/1530386 @@ -0,0 +1,66 @@ +graphic: 0.916 +performance: 0.802 +user-level: 0.790 +device: 0.783 +boot: 0.726 +ppc: 0.687 +semantic: 0.684 +PID: 0.674 +architecture: 0.666 +socket: 0.663 +debug: 0.652 +mistranslation: 0.640 +peripherals: 0.638 +register: 0.634 +files: 0.629 +i386: 0.622 +vnc: 0.580 +network: 0.561 +permissions: 0.557 +x86: 0.488 +kernel: 0.442 +TCG: 0.438 +arm: 0.424 +VMM: 0.414 +hypervisor: 0.396 +virtual: 0.377 +risc-v: 0.345 +assembly: 0.282 +KVM: 0.067 + +command.com on win95 throws video mode out + +on a presumed-good copy of Windows 95 obtained from http://forum.xda-developers.com/showthread.php?t=1960870, the operating system boots successfully and shows up fine, but as soon as I double-click the MS-DOS icon, the window, while remaining the same size, goes to a different resolution and only shows a small portion of what it did, with strange colors and artifacts. tried first with the Debian 2.5 package, then with latest cvs sources, then with the 2.5.0 release, all the same problem. + +jcomeau@aspire:/usr/src/qemu-2.5.0/build$ cd /tmp/win95/SDL/ +jcomeau@aspire:/tmp/win95/SDL$ /usr/src/qemu-2.5.0/build/i386-softmmu/qemu-system-i386 c.img +jcomeau@aspire:/tmp/win95/SDL$ /usr/src/qemu-2.5.0/build/i386-softmmu/qemu-system-i386 --version +QEMU emulator version 2.5.0, Copyright (c) 2003-2008 Fabrice Bellard + + + +verified that the problem does not exist on bochs version 2.6-5 Debian package. I first had to convert the image from qcow to raw: qemu-img convert -O raw c.img c_raw.img + +bxrc file: + +megs: 32 +vga: extension=vbe +romimage: file=$BXSHARE/BIOS-bochs-latest +vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest +cpu: count=1, ips=100000000, reset_on_triple_fault=1 +boot: disk +ata0-master: type=disk, path="/tmp/c_raw.img" +#info: action=report +#debug: action=report +log: /tmp/bochs-win95.log +mouse: enabled=0 +vga_update_interval: 150000 + +command line: bochs -q -f /tmp/bochs.bxrc + +screenshot attached. + +Can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1534683 b/results/classifier/118/graphic/1534683 new file mode 100644 index 000000000..610a23f87 --- /dev/null +++ b/results/classifier/118/graphic/1534683 @@ -0,0 +1,48 @@ +graphic: 0.970 +device: 0.918 +peripherals: 0.909 +semantic: 0.682 +register: 0.678 +architecture: 0.670 +user-level: 0.663 +mistranslation: 0.646 +performance: 0.641 +PID: 0.637 +ppc: 0.623 +network: 0.621 +vnc: 0.617 +hypervisor: 0.586 +debug: 0.583 +x86: 0.572 +i386: 0.558 +virtual: 0.546 +VMM: 0.503 +socket: 0.474 +risc-v: 0.457 +boot: 0.454 +arm: 0.438 +files: 0.432 +permissions: 0.417 +assembly: 0.391 +TCG: 0.304 +kernel: 0.239 +KVM: 0.225 + +no mouse cursor / qxl / windows seven guest + +Hello, +When i'm using qxl graphic card with qemu 2.4.1 , and sdl2 client ( display ) , in a windows seven guest vm , there's no mouse cursor. +I'm using last qxl driver. + +With windows8.1 , there is no problem, mouse cursor is present. + +I need this to use two monitor with a windows guest, + +any suggestions are welcome, +Regards, + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1536 b/results/classifier/118/graphic/1536 new file mode 100644 index 000000000..f60c988d5 --- /dev/null +++ b/results/classifier/118/graphic/1536 @@ -0,0 +1,46 @@ +graphic: 0.981 +semantic: 0.928 +performance: 0.922 +peripherals: 0.908 +device: 0.901 +virtual: 0.900 +hypervisor: 0.884 +architecture: 0.882 +PID: 0.881 +ppc: 0.880 +network: 0.879 +TCG: 0.873 +socket: 0.872 +register: 0.868 +debug: 0.854 +risc-v: 0.845 +x86: 0.845 +arm: 0.842 +permissions: 0.834 +kernel: 0.830 +KVM: 0.818 +vnc: 0.816 +user-level: 0.815 +VMM: 0.810 +assembly: 0.787 +boot: 0.785 +files: 0.768 +i386: 0.726 +mistranslation: 0.579 + +Test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le) +Description of problem: +Some of the test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le). +Steps to reproduce: +1. Download the vsx_mask_extract_runnable_test_030723.c test program from https://gist.githubusercontent.com/johnplatts/db0e9f6683e85e9288fde5c031b3c0e5/raw/ccfb8170f3e613398750830451eebb362875493d/vsx_mask_extract_runnable_test_030723.c. +2. Install the ppc64 gcc cross-compiler and required libraries, which can be done using the ```sudo apt install build-essential gdb-multiarch g++-12-powerpc64-linux-gnu binutils-powerpc64-linux-gnu binutils-powerpc64-linux-gnu-dbg libc6-ppc64-cross libstdc++6-ppc64-cross``` command on Ubuntu 22.04. +3. Compile the vsx_mask_extract_runnable_test_030723.c test program downloaded in step 1 using the ```powerpc64-linux-gnu-gcc-12``` cross-compiler with the ```-mcpu=power10``` option. +4. Execute the program compiled in step 3 using the ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu qemu-ppc64 -cpu power10 ./vsx_mask_extract_runnable_test_030723``` command. + +The issue can also be reproduced by compiling Google Highway and running its unit tests as follows: +1. Clone the Google Highway git repository by running the ```git clone https://github.com/google/highway.git google_highway``` command. +2. Create a ```hwy_ppcbe10_build``` directory inside of the ```google_highway``` directory created in step #1. +3. In the ```hwy_ppc10be_build``` directory created in the previous step, execute the following commands: + - ```CC=powerpc64-linux-gnu-gcc-12 CXX=powerpc64-linux-gnu-g++-12 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CXX_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CROSSCOMPILING=true -DCMAKE_CROSSCOMPILING_EMULATOR='/usr/local/bin/qemu-ppc64;-cpu;power10' -DCMAKE_C_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824' -DCMAKE_CXX_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824'``` + - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu make``` + - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ctest -j``` diff --git a/results/classifier/118/graphic/1537 b/results/classifier/118/graphic/1537 new file mode 100644 index 000000000..6e8e17fb1 --- /dev/null +++ b/results/classifier/118/graphic/1537 @@ -0,0 +1,41 @@ +graphic: 0.977 +files: 0.960 +boot: 0.934 +performance: 0.892 +device: 0.887 +semantic: 0.844 +TCG: 0.812 +architecture: 0.750 +debug: 0.689 +PID: 0.687 +user-level: 0.650 +register: 0.643 +permissions: 0.632 +assembly: 0.629 +mistranslation: 0.612 +vnc: 0.493 +arm: 0.419 +x86: 0.353 +socket: 0.347 +VMM: 0.345 +risc-v: 0.332 +ppc: 0.280 +i386: 0.226 +virtual: 0.169 +peripherals: 0.078 +hypervisor: 0.075 +KVM: 0.069 +network: 0.063 +kernel: 0.039 + +One-floppy windows 3.11 file manager does not work in tcg mode +Description of problem: +When I try to boot mini win 3.11 from https://archive.org/details/mwin-3 it boots into desktop ok, but double-clicking on file manager icon result in black window/GPF (briefly flashing text I can't fully read). + +Starting it with boot choice 2 - with emm386 - same action result in machine reboot. + +Using same disk with kvm works for choice #2 (boot with emm386) +Steps to reproduce: +1. Download IMG file from Arhivce org +2. Run it like I shown above +3. Any (out of two) boot choices lead to same outcome - desktop and say ms-dos console works, but launching file manager gives you black screen/error diff --git a/results/classifier/118/graphic/1546680 b/results/classifier/118/graphic/1546680 new file mode 100644 index 000000000..985954719 --- /dev/null +++ b/results/classifier/118/graphic/1546680 @@ -0,0 +1,52 @@ +graphic: 0.822 +architecture: 0.727 +device: 0.686 +ppc: 0.618 +vnc: 0.368 +PID: 0.367 +hypervisor: 0.366 +network: 0.364 +socket: 0.363 +files: 0.343 +semantic: 0.333 +boot: 0.320 +register: 0.308 +permissions: 0.254 +arm: 0.249 +risc-v: 0.236 +assembly: 0.208 +performance: 0.203 +debug: 0.185 +x86: 0.181 +peripherals: 0.167 +mistranslation: 0.167 +user-level: 0.140 +VMM: 0.117 +TCG: 0.110 +virtual: 0.110 +i386: 0.096 +KVM: 0.074 +kernel: 0.069 + +Incorrect display colors when running big endian guest on POWER8 little endian host + +When running a big endian CentOS guest on a little endian host system the display shows severe color issues, probably due to endianness not being properly detected / switched in the emulated display hardware. Little endian guests show no display issues on the same host hardware and software. + +See attachment for an example of the problem. + + + +Which version of QEMU are you using? How did you start QEMU (i.e. which kind of graphics card did you specify)? And which version of CentOS are you using for the guest? + +QEMU emulator version 2.6.0 (Debian 1:2.6+dfsg-3), Copyright (c) 2003-2008 Fabrice Bellard + +qemu-system-ppc64 --enable-kvm -M pseries -cpu host -m 3G -cdrom Fedora-Server-dvd-ppc64-24-1.2.iso + +Fedora 24 Server + + + +IIRC there were some endianess fixes for this in the past ... can you still reproduce this issue with the latest version of QEMU and a recent kernel? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1550 b/results/classifier/118/graphic/1550 new file mode 100644 index 000000000..0b8e6174d --- /dev/null +++ b/results/classifier/118/graphic/1550 @@ -0,0 +1,46 @@ +graphic: 0.972 +x86: 0.960 +architecture: 0.884 +performance: 0.857 +device: 0.784 +semantic: 0.763 +ppc: 0.712 +i386: 0.705 +peripherals: 0.693 +VMM: 0.671 +permissions: 0.660 +PID: 0.603 +boot: 0.585 +TCG: 0.529 +debug: 0.502 +kernel: 0.495 +network: 0.489 +register: 0.477 +socket: 0.471 +risc-v: 0.468 +vnc: 0.463 +mistranslation: 0.444 +files: 0.424 +arm: 0.414 +KVM: 0.411 +user-level: 0.372 +hypervisor: 0.291 +virtual: 0.250 +assembly: 0.216 + +Crazy mouse movement when passing `-M pc,vmport=off -accel kvm -vga virtio` at the same time +Description of problem: +The mouse cursor is unusable in an x86 guest (disappears, jumps around like crazy) in a graphical environment when `-M pc,vmport=off -accel kvm -vga virtio` is given at the same time. +Steps to reproduce: +1. Download https://download.manjaro.org/xfce/22.0.5/manjaro-xfce-22.0.5-230316-linux61.iso +2. Start above command +3. Wait until the graphical desktop appears +4. Click inside the window and move the mouse + +-> Mouse cursor disappears or jumps around like crazy +Additional information: +If vmport=off is **not** passed, at some point during startup (before graphical login manager appears) the guest switches to use vmmouse from PS/2 mouse. There it also requests usage of absolute input coordinates (VMMOUSE_REQUEST_ABSOLUTE). This code path works normal. Therefore the culprit might be in the guest. + +Another way to reproduce the issue is to use -accel whpx under Windows host (no need to pass vmport=off there). It can be observed that the same guest doesn't attempt to switch to vmmouse there, just like passing vmport=off under Linux. + +The problem does not exist on Linux host when -accel tcg is used in which case the guest doesn't attempt to switch to vmmouse. diff --git a/results/classifier/118/graphic/1553 b/results/classifier/118/graphic/1553 new file mode 100644 index 000000000..279acd093 --- /dev/null +++ b/results/classifier/118/graphic/1553 @@ -0,0 +1,42 @@ +graphic: 0.872 +files: 0.846 +socket: 0.785 +device: 0.779 +arm: 0.777 +network: 0.542 +architecture: 0.512 +PID: 0.480 +semantic: 0.448 +vnc: 0.445 +TCG: 0.362 +ppc: 0.328 +peripherals: 0.314 +debug: 0.276 +mistranslation: 0.229 +permissions: 0.223 +VMM: 0.220 +risc-v: 0.166 +register: 0.157 +kernel: 0.156 +boot: 0.147 +hypervisor: 0.131 +i386: 0.098 +user-level: 0.097 +performance: 0.086 +x86: 0.069 +virtual: 0.057 +assembly: 0.040 +KVM: 0.023 + +Build error: implicit declaration of function 'qemu_close_to_socket' +Description of problem: +When build the latest master code with MSYS2 on Windows 10, GCC reports: +../ui/spice-core.c: In function 'watch_remove': +../ui/spice-core.c:152:5: error: implicit declaration of function 'qemu_close_to_socket' [-Werror=implicit-function-declaration] + 152 | qemu_close_to_socket(watch->fd); + | ^~~~~~~~~~~~~~~~~~~~ +../ui/spice-core.c:152:5: error: nested extern declaration of 'qemu_close_to_socket' [-Werror=nested-externs] +Steps to reproduce: +1. ./configure --enable-sdl --enable-gtk --target-list=arm-softmmu,aarch64-softmmu +2. cd build +3. make diff --git a/results/classifier/118/graphic/1554 b/results/classifier/118/graphic/1554 new file mode 100644 index 000000000..7c25d31e1 --- /dev/null +++ b/results/classifier/118/graphic/1554 @@ -0,0 +1,36 @@ +graphic: 0.861 +mistranslation: 0.709 +device: 0.675 +semantic: 0.550 +user-level: 0.525 +PID: 0.459 +vnc: 0.422 +performance: 0.412 +socket: 0.370 +TCG: 0.364 +network: 0.364 +register: 0.340 +debug: 0.334 +VMM: 0.324 +risc-v: 0.295 +kernel: 0.276 +x86: 0.257 +i386: 0.246 +arm: 0.245 +boot: 0.243 +ppc: 0.222 +architecture: 0.213 +files: 0.183 +permissions: 0.173 +KVM: 0.157 +peripherals: 0.117 +hypervisor: 0.107 +virtual: 0.106 +assembly: 0.084 + +I want get a qemu-img tool,which can run in Any linux operating system, what can i do? +Description of problem: +As we known,qemu-img depends on many dynamic libraries,it can't run in other os if libraries is not support.whether qemu can use static compilation to solve this problem？ + + +i refer to this [issue 1190](https://gitlab.com/qemu-project/qemu/-/issues/1190),but when compile over,it not generate a static qemu-img. Or it has other functions to get a qemu-img which can run in Any linux operating system? diff --git a/results/classifier/118/graphic/1554451 b/results/classifier/118/graphic/1554451 new file mode 100644 index 000000000..2674b47c4 --- /dev/null +++ b/results/classifier/118/graphic/1554451 @@ -0,0 +1,50 @@ +graphic: 0.925 +network: 0.903 +x86: 0.893 +device: 0.842 +mistranslation: 0.839 +hypervisor: 0.821 +performance: 0.783 +i386: 0.770 +user-level: 0.754 +virtual: 0.747 +semantic: 0.723 +architecture: 0.697 +arm: 0.697 +debug: 0.694 +PID: 0.693 +permissions: 0.688 +kernel: 0.683 +files: 0.660 +ppc: 0.643 +register: 0.622 +VMM: 0.608 +risc-v: 0.599 +vnc: 0.597 +socket: 0.577 +peripherals: 0.574 +assembly: 0.533 +KVM: 0.450 +TCG: 0.435 +boot: 0.422 + +unable to create preallocated image with gluster network protocol + +Unable to create preallocated image with gluster protocol + +Version: qemu-img-0.12.1.2-2.479.el6.x86_64 +Platform: RHEL 6 +I have tried creating preallocated image as follows : + +qemu-img create -f qcow2 -o preallocation=full gluster://localhost/vol1/vm1.img 10G + +I see error a follows : +[root@ ]# qemu-img create -f qcow2 -o preallocation=full gluster://localhost/rep3vol/vm1.img 5G +Formatting 'gluster://dhcp37-61.lab.eng.blr.redhat.com/rep3vol/newvm3.img', fmt=qcow2 size=3221225472 encryption=off cluster_size=65536 preallocation='full' +Unknown option 'preallocation' + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1555452 b/results/classifier/118/graphic/1555452 new file mode 100644 index 000000000..36549c5c6 --- /dev/null +++ b/results/classifier/118/graphic/1555452 @@ -0,0 +1,47 @@ +graphic: 0.878 +mistranslation: 0.724 +socket: 0.723 +network: 0.715 +device: 0.706 +debug: 0.676 +semantic: 0.658 +performance: 0.620 +architecture: 0.617 +user-level: 0.613 +PID: 0.590 +files: 0.552 +register: 0.523 +i386: 0.501 +ppc: 0.500 +permissions: 0.493 +assembly: 0.476 +virtual: 0.475 +risc-v: 0.466 +vnc: 0.449 +VMM: 0.439 +arm: 0.415 +TCG: 0.408 +hypervisor: 0.397 +peripherals: 0.382 +kernel: 0.371 +KVM: 0.321 +boot: 0.304 +x86: 0.155 + +GDB server does not work in Windows + +I build qemu with msys2, MINGW64. After fix the socket_error() problem, and manually specify to use IPv4, GDB server still does not work. The related qemu command is +"-monitor none -nographic -gdb tcp::1234 -S" +GDB reports "Timed out" + +There's a message at https://<email address hidden>/msg357981.html. +I've fixed the socket_error() problem. +I see that qio_channel_create_socket_watch is called. + +It seems that someone is fixing this at https://<email address hidden>/msg358825.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. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1556 b/results/classifier/118/graphic/1556 new file mode 100644 index 000000000..4b7b1b634 --- /dev/null +++ b/results/classifier/118/graphic/1556 @@ -0,0 +1,65 @@ +graphic: 0.842 +architecture: 0.789 +performance: 0.769 +ppc: 0.759 +peripherals: 0.745 +device: 0.730 +hypervisor: 0.682 +files: 0.655 +mistranslation: 0.568 +permissions: 0.537 +boot: 0.528 +risc-v: 0.517 +semantic: 0.502 +kernel: 0.500 +vnc: 0.496 +network: 0.476 +PID: 0.473 +socket: 0.454 +debug: 0.404 +user-level: 0.403 +VMM: 0.375 +arm: 0.371 +register: 0.282 +TCG: 0.234 +virtual: 0.201 +x86: 0.179 +KVM: 0.145 +assembly: 0.136 +i386: 0.089 + +RISCV HGATP CSR writes incorrect +Description of problem: +Issue with CSR writes/reads of SATP and HGATP. +Starting with SATP, in file `qemu/target/riscv/csr.c` the function write_satp has the following code snippet: + +```C + if (riscv_cpu_mxl(env) == MXL_RV32) { + vm = validate_vm(env, get_field(val, SATP32_MODE)); + mask = (val ^ env->satp) & (SATP32_MODE | SATP32_ASID | SATP32_PPN); + } else { + vm = validate_vm(env, get_field(val, SATP64_MODE)); + mask = (val ^ env->satp) & (SATP64_MODE | SATP64_ASID | SATP64_PPN); + } + + if (vm && mask) { + if (env->priv == PRV_S && get_field(env->mstatus, MSTATUS_TVM)) { + return RISCV_EXCP_ILLEGAL_INST; +``` +The potential problem I see in the code is that a CSR write which is either illegal or the same as what was previously in the CSR will not yield an illegal instruction. This potential issue could be simple to fix by simply moving the TVM check outside the vm && mask if-statement. +EDIT: I haven't been able to replicate this. Maybe there is code somewhere else which guards against this situation, I'll leave this comment here anyway just to get an extra pair of eyes on this code. + +For writes to hgatp (in the same source file) the value provided to the function is simply written directly to hgatp. +``` +static RISCVException write_hgatp(CPURISCVState *env, int csrno, + target_ulong val) +{ + env->hgatp = val; + return RISCV_EXCP_NONE; +} +``` +This can not be correct, the specification for example states `"A write to hgatp with an unsupported MODE value is not ignored as it is for satp. Instead, the fields of hgatp are WARL in the normal way, when so indicated."` Furthermore, there is also a restriction on the ppn field saying that ppn[1:0] must be 0. Finally when reading hgatp the tvm flag is not taken into consideration at all. +Additional information: +The provided binary should be able to replicate the issue. The error regarding num_unexp_trap can be disregarded in this case, normally I break a test directly on an assertion failure but I didn't this time which is why the counter is increasing. + +[main](/uploads/31ef3bc424d63097177cba3579d9b411/main) diff --git a/results/classifier/118/graphic/1571084 b/results/classifier/118/graphic/1571084 new file mode 100644 index 000000000..f8ecd2226 --- /dev/null +++ b/results/classifier/118/graphic/1571084 @@ -0,0 +1,172 @@ +graphic: 0.890 +register: 0.885 +semantic: 0.875 +arm: 0.875 +permissions: 0.872 +architecture: 0.871 +performance: 0.869 +assembly: 0.866 +virtual: 0.849 +debug: 0.829 +socket: 0.825 +kernel: 0.822 +hypervisor: 0.817 +vnc: 0.813 +TCG: 0.810 +PID: 0.807 +network: 0.806 +peripherals: 0.805 +files: 0.799 +boot: 0.797 +device: 0.787 +KVM: 0.772 +risc-v: 0.758 +ppc: 0.751 +VMM: 0.712 +x86: 0.711 +user-level: 0.706 +mistranslation: 0.690 +i386: 0.666 + +Qemu 2.x dont build on last Gtk dev 3.0+ + +here the build exit + +ui/gtk.c: In function ‘gd_mouse_set’: +ui/gtk.c:479:5: error: ‘gdk_display_get_device_manager’ is deprecated: Use 'gdk_display_get_default_seat' instead [-Werror=deprecated-declarations] + mgr = gdk_display_get_device_manager(dpy); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdisplay.h:170:20: note: declared here + GdkDeviceManager * gdk_display_get_device_manager (GdkDisplay *display); + ^ +ui/gtk.c:482:5: error: ‘gdk_device_manager_get_client_pointer’ is deprecated [-Werror=deprecated-declarations] + gdk_device_warp(gdk_device_manager_get_client_pointer(mgr), + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevicemanager.h:44:14: note: declared here + GdkDevice * gdk_device_manager_get_client_pointer (GdkDeviceManager *device_manager); + ^ +ui/gtk.c: In function ‘gd_grab_devices’: +ui/gtk.c:1316:5: error: ‘gdk_display_get_device_manager’ is deprecated: Use 'gdk_display_get_default_seat' instead [-Werror=deprecated-declarations] + GdkDeviceManager *mgr = gdk_display_get_device_manager(display); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdisplay.h:170:20: note: declared here + GdkDeviceManager * gdk_display_get_device_manager (GdkDisplay *display); + ^ +ui/gtk.c:1317:5: error: ‘gdk_device_manager_list_devices’ is deprecated [-Werror=deprecated-declarations] + GList *devs = gdk_device_manager_list_devices(mgr, GDK_DEVICE_TYPE_MASTER); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevicemanager.h:41:14: note: declared here + GList * gdk_device_manager_list_devices (GdkDeviceManager *device_manager, + ^ +ui/gtk.c:1327:13: error: ‘gdk_device_grab’ is deprecated: Use 'gdk_seat_grab' instead [-Werror=deprecated-declarations] + gdk_device_grab(dev, win, GDK_OWNERSHIP_NONE, FALSE, + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdnd.h:33:0, + from /usr/local/include/gtk-3.0/gdk/gdkevents.h:34, + from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:31, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevice.h:250:15: note: declared here + GdkGrabStatus gdk_device_grab (GdkDevice *device, + ^ +ui/gtk.c:1330:13: error: ‘gdk_device_ungrab’ is deprecated: Use 'gdk_seat_ungrab' instead [-Werror=deprecated-declarations] + gdk_device_ungrab(dev, GDK_CURRENT_TIME); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdnd.h:33:0, + from /usr/local/include/gtk-3.0/gdk/gdkevents.h:34, + from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:31, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevice.h:259:15: note: declared here + void gdk_device_ungrab (GdkDevice *device, + ^ +ui/gtk.c: In function ‘gd_grab_pointer’: +ui/gtk.c:1392:5: error: ‘gdk_display_get_device_manager’ is deprecated: Use 'gdk_display_get_default_seat' instead [-Werror=deprecated-declarations] + GdkDeviceManager *mgr = gdk_display_get_device_manager(display); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdisplay.h:170:20: note: declared here + GdkDeviceManager * gdk_display_get_device_manager (GdkDisplay *display); + ^ +ui/gtk.c:1400:5: error: ‘gdk_device_manager_get_client_pointer’ is deprecated [-Werror=deprecated-declarations] + gdk_device_get_position(gdk_device_manager_get_client_pointer(mgr), + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevicemanager.h:44:14: note: declared here + GdkDevice * gdk_device_manager_get_client_pointer (GdkDeviceManager *device_manager); + ^ +ui/gtk.c: In function ‘gd_ungrab_pointer’: +ui/gtk.c:1432:5: error: ‘gdk_display_get_device_manager’ is deprecated: Use 'gdk_display_get_default_seat' instead [-Werror=deprecated-declarations] + GdkDeviceManager *mgr = gdk_display_get_device_manager(display); + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdisplay.h:170:20: note: declared here + GdkDeviceManager * gdk_display_get_device_manager (GdkDisplay *display); + ^ +ui/gtk.c:1434:5: error: ‘gdk_device_manager_get_client_pointer’ is deprecated [-Werror=deprecated-declarations] + gdk_device_warp(gdk_device_manager_get_client_pointer(mgr), + ^ +In file included from /usr/local/include/gtk-3.0/gdk/gdkdisplay.h:32:0, + from /usr/local/include/gtk-3.0/gdk/gdkscreen.h:32, + from /usr/local/include/gtk-3.0/gdk/gdkapplaunchcontext.h:31, + from /usr/local/include/gtk-3.0/gdk/gdk.h:32, + from /usr/local/include/gtk-3.0/gtk/gtk.h:30, + from /home/amigaone/src/qemu/include/ui/gtk.h:9, + from ui/gtk.c:42: +/usr/local/include/gtk-3.0/gdk/gdkdevicemanager.h:44:14: note: declared here + GdkDevice * gdk_device_manager_get_client_pointer (GdkDeviceManager *device_manager); + ^ + +Thanks for the bug report. You can avoid this being a compilation failure by passing configure the option "--disable-werror". (This is the default for releases, so you only need it for building QEMU from git (a build from a release tarball or a release candidate tarball should be fine). + + diff --git a/results/classifier/118/graphic/1581 b/results/classifier/118/graphic/1581 new file mode 100644 index 000000000..ddcca26be --- /dev/null +++ b/results/classifier/118/graphic/1581 @@ -0,0 +1,44 @@ +TCG: 0.994 +graphic: 0.966 +i386: 0.843 +device: 0.704 +semantic: 0.625 +PID: 0.579 +architecture: 0.506 +performance: 0.491 +ppc: 0.468 +boot: 0.467 +x86: 0.425 +vnc: 0.419 +socket: 0.397 +debug: 0.365 +register: 0.355 +risc-v: 0.340 +network: 0.293 +files: 0.286 +arm: 0.282 +permissions: 0.277 +VMM: 0.274 +user-level: 0.271 +mistranslation: 0.243 +peripherals: 0.194 +hypervisor: 0.185 +virtual: 0.143 +assembly: 0.086 +KVM: 0.014 +kernel: 0.008 + +QEMU TCG crashes when running on windows +Description of problem: +QEMU crashes immediately after startup and shows an assertion failure： + +ERROR:C:/msys64/home/xxx/qemu/tcg/i386/tcg-target.c.inc:1085:tcg_out_addi_ptr: assertion failed: (64 == 32) + +Bail out! ERROR:C:/msys64/home/xxx/qemu/tcg/i386/tcg-target.c.inc:1085:tcg_out_addi_ptr: assertion failed: (64 == + 32) +Steps to reproduce: +NA +Additional information: +1. This problem only occurs when the host system is windows, and the same QEMU configuration does not have this problem when the host system is Linux. +2. This problem is related to the -smp parameter of QEMU. If the smp parameter is 1, this problem will not occur. +3. This problem does not exist in the QEMU version 7.2. diff --git a/results/classifier/118/graphic/1587 b/results/classifier/118/graphic/1587 new file mode 100644 index 000000000..779ede768 --- /dev/null +++ b/results/classifier/118/graphic/1587 @@ -0,0 +1,55 @@ +graphic: 0.888 +performance: 0.825 +risc-v: 0.821 +semantic: 0.794 +device: 0.759 +architecture: 0.728 +files: 0.716 +permissions: 0.698 +peripherals: 0.615 +ppc: 0.595 +PID: 0.570 +socket: 0.556 +network: 0.547 +vnc: 0.528 +kernel: 0.528 +i386: 0.516 +mistranslation: 0.483 +x86: 0.477 +arm: 0.402 +debug: 0.394 +hypervisor: 0.379 +register: 0.371 +boot: 0.357 +assembly: 0.348 +VMM: 0.341 +user-level: 0.336 +TCG: 0.316 +virtual: 0.244 +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/118/graphic/1589272 b/results/classifier/118/graphic/1589272 new file mode 100644 index 000000000..d44c33d13 --- /dev/null +++ b/results/classifier/118/graphic/1589272 @@ -0,0 +1,123 @@ +graphic: 0.872 +register: 0.866 +semantic: 0.844 +arm: 0.826 +virtual: 0.814 +permissions: 0.812 +device: 0.803 +debug: 0.802 +TCG: 0.802 +peripherals: 0.791 +architecture: 0.790 +assembly: 0.789 +vnc: 0.778 +PID: 0.778 +performance: 0.764 +boot: 0.755 +VMM: 0.754 +x86: 0.742 +socket: 0.726 +hypervisor: 0.726 +KVM: 0.724 +ppc: 0.700 +risc-v: 0.696 +kernel: 0.692 +user-level: 0.685 +i386: 0.675 +mistranslation: 0.667 +files: 0.651 +network: 0.606 + +qemu-system-x86_64: There is no option group 'vnc' + +build qemu from git (6b3532b20b787cbd697a68b383232f5c3b39bd1e) + +with this options: + +./configure \ + --python=/usr/bin/python2 \ + --prefix=/usr \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --libexecdir=/usr/lib/qemu \ + --target-list=i386-softmmu,x86_64-softmmu,i386-linux-user,x86_64-linux-user \ + --audio-drv-list='pa alsa' \ + --enable-linux-aio \ + --enable-seccomp \ + --enable-tpm \ + --enable-modules \ + --disable-sdl \ + --disable-gtk \ + --disable-spice \ + --disable-rbd \ + --disable-libiscsi \ + --disable-libnfs \ + --disable-smartcard \ + --disable-glusterfs \ + --disable-docs \ + --disable-vnc{,-sasl,-jpeg,-png} \ + --disable-guest-agent + +i get: + +└───╼ qemu-system-x86_64 +qemu-system-x86_64: There is no option group 'vnc' +Segment Fault (core dumped) + +└───╼ coredumpctl info 12932 + PID: 12932 (qemu-system-x86) + UID: 1000 (sl1pkn07) + GID: 100 (users) + Signal: 11 (SEGV) + Timestamp: dom 2016-06-05 18:05:51 CEST (17s ago) + Command Line: qemu-system-x86_64 + Executable: /usr/bin/qemu-system-x86_64 + Control Group: /user.slice/user-1000.slice/session-c1.scope + Unit: session-c1.scope + Slice: user-1000.slice + Session: c1 + Owner UID: 1000 (sl1pkn07) + Boot ID: 5b205159fa6b4c25946fad7087bd366f + Machine ID: c20ee0c57658685bfedf50384b0e3ec0 + Hostname: sL1pKn07 + Coredump: /var/lib/systemd/coredump/core.qemu-system-x86.1000.5b205159fa6b4c25946fad7087bd366f.12932.1465142751000000000000.lz4 + Message: Process 12932 (qemu-system-x86) of user 1000 dumped core. + + Stack trace of thread 12932: + #0 0x000055b269c2e245 qemu_opts_foreach (qemu-system-x86_64) + #1 0x000055b2698fb6b5 main (qemu-system-x86_64) + #2 0x00007fafc4e5a741 __libc_start_main (libc.so.6) + #3 0x000055b269900eb9 _start (qemu-system-x86_64) + + Stack trace of thread 12934: + #0 0x00007fafc51e80af pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) + #1 0x000055b269c21b19 qemu_cond_wait (qemu-system-x86_64) + #2 0x000055b26992bff4 qemu_tcg_cpu_thread_fn (qemu-system-x86_64) + #3 0x00007fafc51e2484 start_thread (libpthread.so.0) + #4 0x00007fafc4f216dd __clone (libc.so.6) + + Stack trace of thread 12933: + #0 0x00007fafc51eaebc __lll_lock_wait (libpthread.so.0) + #1 0x00007fafc51e4b45 pthread_mutex_lock (libpthread.so.0) + #2 0x000055b269c21a39 qemu_mutex_lock (qemu-system-x86_64) + #3 0x000055b26992bf51 qemu_mutex_lock_iothread (qemu-system-x86_64) + #4 0x000055b269c30430 call_rcu_thread (qemu-system-x86_64) + #5 0x00007fafc51e2484 start_thread (libpthread.so.0) + #6 0x00007fafc4f216dd __clone (libc.so.6) + +builded with GCC 6.1.1 + +greetings + +any notice of this? + +the latest commit i can works with with qemu is 70f87e0 + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +This is fixed long time ago + +Greetings + +OK, thanks, so marking this as "Fix released" now + diff --git a/results/classifier/118/graphic/1593 b/results/classifier/118/graphic/1593 new file mode 100644 index 000000000..f35af0504 --- /dev/null +++ b/results/classifier/118/graphic/1593 @@ -0,0 +1,37 @@ +graphic: 0.927 +network: 0.834 +device: 0.799 +socket: 0.759 +mistranslation: 0.506 +vnc: 0.472 +debug: 0.469 +files: 0.466 +risc-v: 0.460 +arm: 0.430 +ppc: 0.404 +register: 0.402 +PID: 0.395 +kernel: 0.382 +architecture: 0.377 +TCG: 0.367 +boot: 0.330 +i386: 0.320 +semantic: 0.276 +x86: 0.272 +hypervisor: 0.267 +user-level: 0.250 +permissions: 0.245 +VMM: 0.219 +virtual: 0.199 +performance: 0.191 +peripherals: 0.187 +assembly: 0.155 +KVM: 0.145 + +SLIRP hostfwd ignores bind address and uses `INADDR_ANY` +Description of problem: +When using `-netdev hostfwd=`..., qemu SLIRP uses `INADDR_ANY` instead of any bind address provided by the user. As a result, even if the user specifies to listen only on localhost (e.g. `-netdev user,hostfwd=tcp:127.0.0.1:22-:22`), qemu will listen on `*.*`. This is a potential security issue (as it may unexpectedly expose the guest to internet or local network traffic). +Additional information: +The bug is here: https://gitlab.com/qemu-project/qemu/-/blob/master/net/slirp.c#L777 + +Rather than hardcoding `INADDR_ANY`, qemu should respect the user-defined bind address. diff --git a/results/classifier/118/graphic/1596 b/results/classifier/118/graphic/1596 new file mode 100644 index 000000000..27dea8d5a --- /dev/null +++ b/results/classifier/118/graphic/1596 @@ -0,0 +1,50 @@ +graphic: 0.997 +device: 0.943 +semantic: 0.905 +vnc: 0.898 +virtual: 0.896 +performance: 0.829 +debug: 0.805 +architecture: 0.799 +ppc: 0.757 +network: 0.710 +hypervisor: 0.636 +register: 0.606 +mistranslation: 0.540 +permissions: 0.539 +arm: 0.535 +PID: 0.499 +assembly: 0.497 +user-level: 0.423 +socket: 0.419 +peripherals: 0.379 +risc-v: 0.315 +boot: 0.303 +x86: 0.253 +files: 0.221 +kernel: 0.210 +VMM: 0.200 +TCG: 0.156 +i386: 0.106 +KVM: 0.020 + +VNC console with 4K resolutions is cut off on the right side and mouse coordinates are offset (or horizontal res greater than 2600-3000 pixels) +Description of problem: +For some reason when connecting to the VNC console of a QEMU VM, when you use a resolution that has its horizontal size of about 3000 pixels or more, it gets cut off by about 1/4 of the screen from the right, and the mouse position is offset by that value towards the left. See image for explanation: + + +Steps to reproduce: +1. Create a Fedora 37 VM +2. Use `virtio-vga-gl` and `egl-headless` +3. Set the resolution to 4K (3840x2160) or anything with the horizontal resolution greater than 3000 pixels +4. Use Windows to connect to the VNC console. Issue happens with TightVNC Viewer and RealVNC Viewer +Additional information: +I also tried `-device virtio-vga-gl,edid=off,xres=3840,yres=2160`. Same result, but `edid=off` helps to make 2560x1600 appear, making it bearable. + +This also happens with Wayland and Xorg. + +Please note that while it's possible to use Gnome's Screen Sharing (RDP/VNC) options, as well as NoMachine or other options, this is an undesirable behavior in QEMU's VNC server/console that should be fixed (and can, the VNC protocol perfectly supports 4K without issues) + +Not to mention that, at least in my use case, the VNC console is faster than the alternatives, even SPICE (connecting from Windows is barely unusable at 4K res - it's a bliss from Linux. Both cases from a remote machine in the same LAN, but that is unrelated to this bug). + +I would happily try different use cases to try to help nail down this bug :smile: diff --git a/results/classifier/118/graphic/1598612 b/results/classifier/118/graphic/1598612 new file mode 100644 index 000000000..4ef4fce00 --- /dev/null +++ b/results/classifier/118/graphic/1598612 @@ -0,0 +1,62 @@ +graphic: 0.858 +device: 0.747 +i386: 0.731 +performance: 0.644 +ppc: 0.620 +network: 0.612 +kernel: 0.602 +vnc: 0.593 +architecture: 0.581 +semantic: 0.562 +permissions: 0.542 +peripherals: 0.541 +user-level: 0.535 +TCG: 0.522 +register: 0.520 +socket: 0.515 +risc-v: 0.508 +files: 0.495 +VMM: 0.480 +PID: 0.474 +virtual: 0.463 +hypervisor: 0.436 +mistranslation: 0.412 +boot: 0.390 +arm: 0.379 +debug: 0.347 +x86: 0.335 +assembly: 0.229 +KVM: 0.211 + +Windows for Workgroups 3.11 installer crashes with a general protection fault + +I used only disk images from here: http://ia801606.us.archive.org/zipview.php?zip=/22/items/IBM_PC_Compatibles_TOSEC_2012_04_23/IBM_PC_Compatibles_TOSEC_2012_04_23.zip + +When I try to install Windows for Workgroups 3.11 on either PC DOS 2000 or MS-DOS 6.22, the installer crashes after entering the graphical part with two dialogs containing: + +Application Error +WINSETUP caused a General Protection Fault in module <unknown>0EDF:7011WINSETUP will close. + +Application Error +WINSETUP caused a General Protection Fault in module USER.EXE at 0001:40B6. + +And then: +Standard Mode: Bad Fault in MS-DOS Extender. +Fault: 000D Stack Dump: 0000 0000 0070 +Raw fault frame: EC=0000 IP=5EF7 CS=037F FL=3087 SP=FFEE SS=02DF + +This happens both with and without KVM. I tested with QEMU from Ubuntu 14.04 and 16.04 and recent GIT (ef8757f1fe8095a256ee617e4dbac69d3b33ae94). + +Windows 3.1 has the same problem, but the errors are slightly different: + +Application Error +WINSETUP caused a General Protection Fault in module <unknown>0C77:7011WINSETUP will close. + +Application Error +WINSETUP caused a General Protection Fault in module KRNL386.EXE at 0001:9F03. + +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/118/graphic/1600563 b/results/classifier/118/graphic/1600563 new file mode 100644 index 000000000..9633cd850 --- /dev/null +++ b/results/classifier/118/graphic/1600563 @@ -0,0 +1,71 @@ +mistranslation: 0.952 +graphic: 0.945 +peripherals: 0.926 +register: 0.888 +KVM: 0.884 +virtual: 0.871 +device: 0.846 +kernel: 0.835 +performance: 0.833 +files: 0.811 +architecture: 0.785 +semantic: 0.750 +user-level: 0.742 +hypervisor: 0.717 +debug: 0.640 +permissions: 0.635 +network: 0.570 +VMM: 0.562 +PID: 0.548 +risc-v: 0.520 +socket: 0.509 +vnc: 0.446 +x86: 0.446 +assembly: 0.397 +boot: 0.393 +ppc: 0.386 +i386: 0.340 +arm: 0.274 +TCG: 0.230 + +min_io_size is currently limited to size uint16_t + +I am using LVM VGs on MD-raid1 for hosting my KVM volumes. On the host, a VG looks like this: + +Disk /dev/vm/vol202a: 60 GiB, 64424509440 bytes, 125829120 sectors +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 4096 bytes +I/O size (minimum/optimal): 131072 bytes / 131072 bytes + +In order to replicate the block device characteristics in the guest, I am using the following extra parameters: + +-set device.scsi0-0-0-0.logical_block_size=512 +-set device.scsi0-0-0-0.physical_block_size=4096 +-set device.scsi0-0-0-0.min_io_size=131072 + +This doesn't work as qemu complains that min_io_size needs to be of type uint16_t. + +The value is set to uint16_t by mistake. The value is passed to Qemu in bytes, but then it is divided by the sector size and passed to the vm in sectors through a 16 bit register field. The vm kernel then multiplies it again by sector size and shows (through /sys/block/x/queue) the value in bytes. Because of this, the input value from the qemu side should be uint32_t. + +A simple patch is attached, correcting the problem. I think some extra logic should be added after dividing by the page size, to prevent overflowing the 16 bit register. + +With that patch, I can pass a 4MB min and optimal io sizes successfully, to match the stripe size used by RBD/Ceph. Sadly though, I see no improvement coming out of it, but I'll document that in a separate bug report. + +root@cephvm:~# lsblk -t +NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME +sda 0 4194304 4194304 512 512 1 noop 128 4096 2G + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1609 b/results/classifier/118/graphic/1609 new file mode 100644 index 000000000..f07ecf900 --- /dev/null +++ b/results/classifier/118/graphic/1609 @@ -0,0 +1,49 @@ +user-level: 0.985 +graphic: 0.979 +assembly: 0.909 +ppc: 0.847 +device: 0.767 +PID: 0.754 +semantic: 0.719 +architecture: 0.691 +files: 0.674 +x86: 0.562 +performance: 0.554 +debug: 0.486 +mistranslation: 0.476 +network: 0.452 +permissions: 0.444 +arm: 0.425 +vnc: 0.419 +socket: 0.410 +i386: 0.364 +VMM: 0.337 +register: 0.321 +risc-v: 0.315 +TCG: 0.309 +boot: 0.306 +virtual: 0.279 +kernel: 0.265 +peripherals: 0.212 +hypervisor: 0.131 +KVM: 0.035 + +SPARC emulation: userspace program run from gdb crashes OS running in emulator +Description of problem: +SPARC emulation: userspace program run from gdb crashes OS running in emulator +Steps to reproduce: +As a user (not root!): +1. as -Q n -K PIC -b -L mandelbrot.s +2. ld -m a.out -o test +3. gdb ./test +4. run + +`as' is from gnu binutils (binutils-2.20.1-sol26-sparc-local.gz). +Additional information: +[mandelbrot.s](/uploads/edfe6f1fd01fa39ecce9ba4201454ae3/mandelbrot.s) + +screenshot: https://imgur.com/a/JD51DJA + +It could very well be a bug in my assembly code, but it is still strange that it crashes the whole system. + +~"kind::Bug"[in_asm.dat.xz](/uploads/6bb43ce2b7d6973da4751d236fb44e12/in_asm.dat.xz) diff --git a/results/classifier/118/graphic/1611979 b/results/classifier/118/graphic/1611979 new file mode 100644 index 000000000..69489151d --- /dev/null +++ b/results/classifier/118/graphic/1611979 @@ -0,0 +1,44 @@ +graphic: 0.871 +device: 0.782 +user-level: 0.581 +ppc: 0.537 +vnc: 0.531 +mistranslation: 0.524 +socket: 0.511 +risc-v: 0.510 +semantic: 0.489 +register: 0.487 +arm: 0.465 +debug: 0.351 +PID: 0.339 +network: 0.320 +boot: 0.310 +TCG: 0.304 +architecture: 0.272 +i386: 0.232 +kernel: 0.183 +virtual: 0.182 +x86: 0.158 +VMM: 0.157 +KVM: 0.048 +files: 0.039 +assembly: 0.015 +peripherals: 0.013 +permissions: 0.012 +hypervisor: 0.011 +performance: 0.006 + +GTK+ interface, backspace is broken in the monitor console + +this has been broken for over 2 years + +Confirmed, this is indeed broken. I sent a patch with a fix to the mailing list: +https://marc.info/?i=1470900060-25821-1-git-send-email-thuth%40redhat.com + +thank you + +Fix has been picked up into the repository now: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=344aa283b89bec2af9761 + +Released with version 2.8 + diff --git a/results/classifier/118/graphic/1614348 b/results/classifier/118/graphic/1614348 new file mode 100644 index 000000000..8bb8d6b81 --- /dev/null +++ b/results/classifier/118/graphic/1614348 @@ -0,0 +1,77 @@ +graphic: 0.925 +architecture: 0.923 +semantic: 0.905 +x86: 0.897 +arm: 0.878 +performance: 0.865 +mistranslation: 0.845 +permissions: 0.821 +user-level: 0.805 +PID: 0.755 +debug: 0.741 +device: 0.721 +files: 0.683 +socket: 0.669 +kernel: 0.625 +ppc: 0.572 +vnc: 0.566 +peripherals: 0.564 +virtual: 0.563 +network: 0.537 +register: 0.536 +assembly: 0.530 +risc-v: 0.508 +TCG: 0.443 +VMM: 0.423 +hypervisor: 0.392 +boot: 0.326 +i386: 0.113 +KVM: 0.108 + +qemu-arm core dumped for no entry symbol programe + +Hi qemu developers, + +Environment: +* Fedora 24 x86_64 +* qemu-arm version 2.6.92, Copyright (c) 2003-2008 Fabrice Bellard +* arm-linux-gnu-gcc 6.1.1 20160621 (Red Hat Cross 6.1.1-2) (GCC) target: arm-linux-gnueabi +* glibc-arm-linux-gnu-devel-2.23 + +very simple hello.c: + +#include <stdio.h> + +int main(int argc, char *argv[]) +{ + printf("Hello World\n"); + + return 0; +} + +arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib -lc + +/usr/bin/arm-linux-gnu-ld: Warning: Cannot find entry symbol _start; defaulting to 00000000000101fc + +qemu-arm -L /usr/arm-linux-gnu ./a.out + +Hello World +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction + +But provided entry symbol: + +arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib /usr/arm-linux-gnu/lib/crt1.o /usr/arm-linux-gnu/lib/crti.o /usr/arm-linux-gnu/lib/crtn.o -lc + +qemu-arm -L /usr/arm-linux-gnu ./a.out is able to work happily! + +Regards, +Leslie Zhai + +file a.out + +a.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=6a86f764c1200a41253e1bc80d3155a295b87818, not stripped + +Why do you think this is a bug in QEMU? This program crashes on exit if you run it on real arm hardware. This is unsurprising as you have told the compiler to build it with no C runtime. The program thus starts at the beginning of 'main', and when it hits the return at the end there is nowhere for it to return to and it crashes. If you link the program with the C runtime the way you are expected to, then the runtime gets control at the start of execution and provides a place for main() to return to. If you choose not to link against the C runtime then it is your responsibility to provide an alternate runtime (including defining an entry point) which implements the semantics that the main() function expects. + + diff --git a/results/classifier/118/graphic/1615 b/results/classifier/118/graphic/1615 new file mode 100644 index 000000000..a1abac140 --- /dev/null +++ b/results/classifier/118/graphic/1615 @@ -0,0 +1,41 @@ +graphic: 0.964 +device: 0.809 +virtual: 0.789 +debug: 0.666 +vnc: 0.642 +performance: 0.601 +semantic: 0.477 +PID: 0.414 +kernel: 0.399 +ppc: 0.369 +boot: 0.348 +risc-v: 0.325 +VMM: 0.312 +files: 0.304 +socket: 0.298 +network: 0.286 +TCG: 0.250 +arm: 0.241 +permissions: 0.230 +KVM: 0.213 +i386: 0.210 +mistranslation: 0.184 +x86: 0.166 +hypervisor: 0.163 +architecture: 0.120 +peripherals: 0.092 +register: 0.078 +user-level: 0.076 +assembly: 0.023 + +8.0.0: Crash when attempting to commit snapshot +Description of problem: +When trying to commit a snapshot to the backing store, qemu exits with the error: + +`qemu: qemu_mutex_unlock_impl: Operation not permitted` +Steps to reproduce: +1. Run qemu command above +2. Open the monitor virtual console (Ctrl-Alt-2) +3. Execute command: `commit os` +Additional information: +Attached are the [backtrace](/uploads/ba8f519e6b00eb054ba416054c782122/8.0.0-1-bt) and the [configure output](/uploads/17124b45e12b252bd01cf41e7a3d2ea4/8.0.0-1-conf.gz). This is a regression from 7.2.1 diff --git a/results/classifier/118/graphic/1615212 b/results/classifier/118/graphic/1615212 new file mode 100644 index 000000000..2828744c4 --- /dev/null +++ b/results/classifier/118/graphic/1615212 @@ -0,0 +1,52 @@ +graphic: 0.984 +performance: 0.925 +device: 0.813 +user-level: 0.731 +network: 0.493 +permissions: 0.471 +vnc: 0.461 +register: 0.428 +debug: 0.418 +mistranslation: 0.373 +PID: 0.338 +semantic: 0.337 +virtual: 0.307 +ppc: 0.276 +risc-v: 0.275 +boot: 0.264 +VMM: 0.250 +arm: 0.247 +socket: 0.216 +i386: 0.200 +x86: 0.176 +TCG: 0.156 +architecture: 0.133 +hypervisor: 0.100 +files: 0.093 +peripherals: 0.087 +kernel: 0.073 +KVM: 0.041 +assembly: 0.007 + +SDL UI switching to monitor half-broken and scrolling broken + +ctrl+alt+2 must be pressed 2 or more times for the monitor console window to appear with -sdl, the window flashes and disappears also before finally staying open + +backspace does not always work in -sdl also, and switching back and forth very quickly from the vga to the monitor windows, it hangs + +you need to do a proper code review of all the user interfaces. + +This is described a bit more here: + + https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg00946.html + +But basically it's a libsdl bug: + + https://bugzilla.libsdl.org/show_bug.cgi?id=3287 + +i see, but there are still problems with the user interfaces. + +did you use SDL1.2 or SDL2 here? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1624 b/results/classifier/118/graphic/1624 new file mode 100644 index 000000000..860176417 --- /dev/null +++ b/results/classifier/118/graphic/1624 @@ -0,0 +1,53 @@ +graphic: 0.892 +architecture: 0.816 +vnc: 0.779 +device: 0.777 +files: 0.727 +debug: 0.703 +VMM: 0.674 +PID: 0.669 +socket: 0.658 +semantic: 0.631 +ppc: 0.631 +network: 0.585 +risc-v: 0.577 +performance: 0.530 +boot: 0.501 +kernel: 0.475 +arm: 0.463 +register: 0.459 +user-level: 0.448 +permissions: 0.421 +TCG: 0.403 +hypervisor: 0.395 +peripherals: 0.389 +assembly: 0.193 +x86: 0.151 +virtual: 0.136 +i386: 0.106 +KVM: 0.091 +mistranslation: 0.081 + +8.0.0: Crash when emulating MIPS executable +Description of problem: +A change to QEMU introduced within the 6.0.0 development cycle causes MIPS executable to crash. +Similar problem occurred within the same time-frame for Aarch64 executables, but was fixed. +Patches in QEMU causing both Aarch64 and MIPS occurrences are identified and attached below. +Steps to reproduce: +1. Download attached core_test.zip archive. +2. Run pre-built MIPS executable with QEMU. +3. Observe the crash somewhere in tdelete. +4. Source for the test is here: https://github.com/VectorChief/QuadRay-engine +5. The binaries were built with GCC 9.4 cross-compilers using slightly modified makefiles (-ggdb3) for gdb-multiarch +6. Building on Ubuntu 22.04 and Ubuntu 23.04 also reproduces the problem, so it's not OS or compiler specific. +Additional information: +Archive with pre-built binaries: [core_test.zip](/uploads/529833c6f83aeec253df647a94868f8a/core_test.zip) + +Patch breaking Aarch64: [qemu_arm_br.diff](/uploads/476321e40a551e964be41a8bfda96613/qemu_arm_br.diff) +commit 8fe35e0444be88de4e3ab80a2a0e210a1f6d663d + +Patch fixing Aarch64: [qemu_arm_fix.diff](/uploads/2db3892d6839e9a4dfaf427359d6f004/qemu_arm_fix.diff) +commit ae30e86661b0f48562cd95918d37cbeec5d02262 + +Patch breaking MIPS: [qemu_mips_br.diff](/uploads/0a482e61c1245e5783364db845a55dfa/qemu_mips_br.diff) +commit 96e5b4c7584d623f6cdcb0083829c19141b2b130 diff --git a/results/classifier/118/graphic/1626 b/results/classifier/118/graphic/1626 new file mode 100644 index 000000000..18b05a88b --- /dev/null +++ b/results/classifier/118/graphic/1626 @@ -0,0 +1,35 @@ +graphic: 0.950 +device: 0.870 +mistranslation: 0.799 +network: 0.748 +arm: 0.694 +VMM: 0.624 +risc-v: 0.603 +ppc: 0.569 +semantic: 0.550 +socket: 0.527 +vnc: 0.517 +i386: 0.509 +TCG: 0.504 +x86: 0.488 +kernel: 0.475 +KVM: 0.418 +boot: 0.364 +debug: 0.343 +hypervisor: 0.332 +architecture: 0.279 +permissions: 0.272 +register: 0.263 +PID: 0.240 +virtual: 0.193 +performance: 0.144 +peripherals: 0.119 +assembly: 0.092 +user-level: 0.060 +files: 0.052 + +QEMU insists on using /var/tmp instead of /tmp +Description of problem: +On a host, our sysadmins have decided for whatever reason that `/var/tmp` is not a thing that normal users can write to (and perhaps that's dumb, but it is what it is and would be a challenging non-technical problem to solve). Whenever QEMU detects the temporary directory is /tmp, it changes it to `/var/tmp` without a mechanism to change it (see https://gitlab.com/qemu-project/qemu/-/commit/69fbfff95e849156985cf95e2010ffc8762e34e6). + +I'm sure in the general case this is fine, but can you add an environment variable or a ./configure option to make this location configurable? I really would like to write to `/tmp`. diff --git a/results/classifier/118/graphic/1629 b/results/classifier/118/graphic/1629 new file mode 100644 index 000000000..622dfe44f --- /dev/null +++ b/results/classifier/118/graphic/1629 @@ -0,0 +1,31 @@ +graphic: 0.994 +mistranslation: 0.585 +performance: 0.395 +ppc: 0.372 +kernel: 0.360 +architecture: 0.242 +device: 0.218 +semantic: 0.211 +VMM: 0.149 +arm: 0.139 +debug: 0.114 +assembly: 0.091 +boot: 0.087 +virtual: 0.084 +vnc: 0.068 +TCG: 0.053 +network: 0.045 +PID: 0.033 +user-level: 0.031 +register: 0.028 +hypervisor: 0.025 +i386: 0.021 +x86: 0.018 +risc-v: 0.015 +socket: 0.013 +KVM: 0.013 +files: 0.011 +peripherals: 0.011 +permissions: 0.008 + +qem-img Heap Buffer Overflow diff --git a/results/classifier/118/graphic/1632 b/results/classifier/118/graphic/1632 new file mode 100644 index 000000000..c0635b045 --- /dev/null +++ b/results/classifier/118/graphic/1632 @@ -0,0 +1,520 @@ +graphic: 0.910 +semantic: 0.899 +peripherals: 0.898 +risc-v: 0.897 +arm: 0.887 +vnc: 0.887 +assembly: 0.881 +register: 0.881 +ppc: 0.879 +PID: 0.879 +architecture: 0.868 +socket: 0.865 +VMM: 0.857 +KVM: 0.852 +permissions: 0.850 +TCG: 0.847 +user-level: 0.837 +debug: 0.830 +device: 0.830 +hypervisor: 0.820 +boot: 0.811 +virtual: 0.783 +kernel: 0.781 +performance: 0.767 +network: 0.761 +x86: 0.724 +files: 0.682 +mistranslation: 0.661 +i386: 0.584 + +Porting support for GVM/AEHD to qemu 8.0 +Description of problem: +I'm trying to find reason why changes work fine with qemu 7.1 but it doesn't work with qemu 7.2 and 8.0. Could you recommend me point where I should investigate this bug/error when using GVM acceleration. I know it is not part of official QEMU and somebody is also working on that [topic ](https://gitlab.com/qemu-project/qemu/-/issues/1558). + + +``` +GVM is operational +** +ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) +** +ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) +Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) +** +ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) + +** +ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) +Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) +** +ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) +Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) +** +ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) + +** +ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) + +** +ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) +Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) +** +ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) + +** +ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) + +** +ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) + +** +ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized)Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) + +Bail out! ERROR:../util/qemu-thread-win32.c:207:qemu_sem_post: assertion failed: (sem->initialized) +``` +Steps to reproduce: +1. Checkout my fork with this branch [qemu-8.0-gvm](https://gitlab.com/MateuszKrawczuk/qemu/-/tree/qemu-8.0-gvm) +2. Build on windows using mingw64 +3. Try launch with using GVM acceleration +Additional information: +``` +./configure --enable-sdl --enable-gtk --enable-whpx --target-list=x86_64-softmmu +Using './build' as the directory for build output +ln: nie udało się utworzyć dowiązania symbolicznego 'x86_64-softmmu/qemu-system-x86_64.exe': No such file or directory +The Meson build system +Version: 0.61.5 +Source dir: C:/Users/AMD-RYZEN-PC/qemu +Build dir: C:/Users/AMD-RYZEN-PC/qemu/build +Build type: native build +Project name: qemu +Project version: 8.0.0 +C compiler for the host machine: cc -m64 -mcx16 (gcc 12.2.0 "cc (Rev10, Built by MSYS2 project) 12.2.0") +C linker for the host machine: cc -m64 -mcx16 ld.bfd 2.40 +Host machine cpu family: x86_64 +Host machine cpu: x86_64 +Program scripts/symlink-install-tree.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/symlink-install-tree.py) +Program sh found: YES (C:\Users\AMD-RYZEN-PC\scoop\apps\msys2\2023-03-18\usr\bin/sh.EXE) +C++ compiler for the host machine: c++ -m64 -mcx16 (gcc 12.2.0 "c++ (Rev10, Built by MSYS2 project) 12.2.0") +C++ linker for the host machine: c++ -m64 -mcx16 ld.bfd 2.40 +Program python3 found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe) +Program bzip2 found: YES (C:\Users\AMD-RYZEN-PC\scoop\apps\msys2\2023-03-18\mingw64\bin/bzip2.EXE) +Program iasl found: NO +Compiler for C supports link arguments -Wl,-z,relro: NO +Compiler for C supports link arguments -Wl,-z,now: NO +Compiler for C supports link arguments -Wl,--no-seh: YES +Compiler for C supports link arguments -Wl,--nxcompat: YES +Compiler for C supports link arguments -Wl,--dynamicbase: YES +Compiler for C supports link arguments -Wl,--high-entropy-va: YES +Compiler for C++ supports link arguments -Wl,--warn-common: YES +Program cgcc found: NO +Library m found: YES +Run-time dependency threads found: YES +Library util found: NO +Program midl found: NO +Program widl found: YES +Library pathcch found: YES +Library ws2_32 found: YES +Library winmm found: YES +Windows resource compiler: GNU windres (GNU Binutils) 2.40 +Has header "WinHvPlatform.h" : YES +Has header "WinHvEmulation.h" : YES +Run-time dependency appleframeworks found: NO (tried framework) +Found pkg-config: C:\Users\AMD-RYZEN-PC\scoop\apps\msys2\2023-03-18\mingw64\bin/pkg-config.EXE (1.8.0) +Run-time dependency gio-2.0 found: YES 2.76.1 +Program C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/gdbus-codegen found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/gdbus-codegen.exe) +Run-time dependency gio-unix-2.0 found: NO (tried pkgconfig) +Run-time dependency pixman-1 found: YES 0.42.2 +Run-time dependency zlib found: YES 1.2.13 +Has header "libaio.h" : NO +Run-time dependency liburing found: NO (tried pkgconfig) +Run-time dependency libnfs found: NO (tried pkgconfig) +Has header "attr/xattr.h" : NO +Run-time dependency appleframeworks found: NO (tried framework) +Run-time dependency appleframeworks found: NO (tried framework) +Run-time dependency libseccomp found: NO (tried pkgconfig) +Has header "cap-ng.h" : NO +Run-time dependency xkbcommon found: NO (tried pkgconfig) +Run-time dependency slirp found: YES 4.7.0 +Has header "libvdeplug.h" : NO +Run-time dependency jack found: NO (tried pkgconfig) +Run-time dependency sndio found: NO (tried pkgconfig) +Run-time dependency spice-protocol found: NO (tried pkgconfig) +Run-time dependency spice-server found: NO (tried pkgconfig) +Library rt found: NO +Run-time dependency libiscsi found: NO (tried pkgconfig) +Run-time dependency libzstd found: YES 1.5.5 +Run-time dependency virglrenderer found: YES 0.9.1 +Run-time dependency blkio found: NO (tried pkgconfig) +Run-time dependency libcurl found: NO (tried pkgconfig) +Run-time dependency ncurses found: NO (tried pkgconfig) +Run-time dependency ncursesw found: YES 6.4.20230211 +Has header "brlapi.h" : NO +Run-time dependency sdl2 found: YES 2.26.5 +Run-time dependency sdl2_image found: YES 2.6.3 +Library rados found: NO +Has header "rbd/librbd.h" : NO +Run-time dependency glusterfs-api found: NO (tried pkgconfig) +Run-time dependency libssh found: NO (tried pkgconfig) +Has header "bzlib.h" : YES +Library bz2 found: YES +Has header "lzfse.h" : NO +Has header "sys/soundcard.h" : NO +Has header "dsound.h" : YES +Run-time dependency epoxy found: YES 1.5.10 +Has header "epoxy/egl.h" with dependency epoxy: YES +Run-time dependency gbm found: NO (tried pkgconfig) +Run-time dependency gnutls found: NO (tried pkgconfig) +Run-time dependency gnutls found: NO (tried pkgconfig) +libgcrypt-config found: NO need ['>=1.8'] +Run-time dependency libgcrypt found: NO (tried config-tool) +Run-time dependency nettle found: NO (tried pkgconfig) +Run-time dependency gmp found: YES 6.2.1 +Run-time dependency gtk+-3.0 found: YES 3.24.38 +Run-time dependency gtk+-x11-3.0 found: NO (tried pkgconfig) +Run-time dependency vte-2.91 found: NO (tried pkgconfig) +Run-time dependency libpng found: YES 1.6.39 +Run-time dependency libjpeg found: YES 2.1.5.1 +Has header "sasl/sasl.h" : NO +Has header "security/pam_appl.h" : NO +Has header "snappy-c.h" : NO +Has header "lzo/lzo1x.h" : YES +Library lzo2 found: YES +Has header "numa.h" : NO +Library ibumad found: NO +Has header "rdma/rdma_cma.h" : NO +Library ibverbs found: NO +Run-time dependency xencontrol found: NO (tried pkgconfig) +Library xenstore found: NO +Library xenctrl found: NO +Library xendevicemodel found: NO +Library xenforeignmemory found: NO +Library xengnttab found: NO +Library xenevtchn found: NO +Library xentoolcore found: NO +Run-time dependency libcacard found: NO (tried pkgconfig) +Run-time dependency u2f-emu found: NO (tried pkgconfig) +Run-time dependency canokey-qemu found: NO (tried pkgconfig) +Run-time dependency libusbredirparser-0.5 found: NO (tried pkgconfig) +Run-time dependency libusb-1.0 found: YES 1.0.26 +Run-time dependency libpmem found: NO (tried pkgconfig) +Run-time dependency libdaxctl found: NO (tried pkgconfig) +Run-time dependency libkeyutils found: NO (tried pkgconfig) +Checking for function "gettid" : NO +Run-time dependency libselinux found: NO (tried pkgconfig) +Run-time dependency fuse3 found: NO (tried pkgconfig) +Run-time dependency libbpf found: NO (tried pkgconfig) +Run-time dependency libdw found: NO (tried pkgconfig) +Checking for function "pthread_fchdir_np" : NO +Has header "sys/epoll.h" : NO +Has header "linux/magic.h" : NO +Has header "valgrind/valgrind.h" : NO +Has header "linux/btrfs.h" : NO +Has header "libdrm/drm.h" : NO +Has header "pty.h" : NO +Has header "sys/disk.h" : NO +Has header "sys/ioccom.h" : NO +Has header "sys/kcov.h" : NO +Has header "afunix.h" : YES +Checking for function "close_range" : NO +Checking for function "accept4" : NO +Checking for function "clock_adjtime" : NO +Checking for function "dup3" : NO +Checking for function "fallocate" : NO +Checking for function "posix_fallocate" : NO +Checking for function "posix_memalign" : NO +Checking for function "_aligned_malloc" : YES +Checking for function "valloc" : NO +Checking for function "memalign" : NO +Checking for function "ppoll" : NO +Checking for function "preadv" : NO +Checking for function "pthread_fchdir_np" : NO (cached) +Checking for function "sendfile" : NO +Checking for function "setns" : NO +Checking for function "syncfs" : NO +Checking for function "sync_file_range" : NO +Checking for function "timerfd_create" : NO +Checking for function "copy_file_range" : NO +Checking for function "getifaddrs" : NO +Checking for function "openpty" with dependency -lutil: NO +Checking for function "strchrnul" : NO +Checking for function "system" : YES +Header <sys/epoll.h> has symbol "epoll_create1" : NO +Header <linux/falloc.h> has symbol "FALLOC_FL_PUNCH_HOLE" : NO +Header <linux/falloc.h> has symbol "FALLOC_FL_ZERO_RANGE" : NO +Has header "linux/fiemap.h" : NO +Checking for function "getrandom" : NO +Header <sys/inotify.h> has symbol "inotify_init" : NO +Header <sys/inotify.h> has symbol "inotify_init1" : NO +Header <sys/prctl.h> has symbol "PR_SET_TIMERSLACK" : NO +Header <linux/rtnetlink.h> has symbol "IFLA_PROTO_DOWN" : NO +Header <sys/sysmacros.h> has symbol "makedev" : NO +Header <getopt.h> has symbol "optreset" : NO +Header <netinet/in.h> has symbol "IPPROTO_MPTCP" : NO +Checking whether type "struct sigevent" has member "sigev_notify_thread_id" : NO +Checking whether type "struct stat" has member "st_atim" : NO +Checking for type "struct iovec" : NO +Checking for type "struct utmpx" : NO +Checking for type "struct mmsghdr" : NO +Header <linux/vm_sockets.h> has symbol "AF_VSOCK" : NO +Has header "vscoordint.h" : NO +Checking if "_lock_file and _unlock_file" : links: YES +Checking if "mingw setjmp and longjmp" : links: NO +Program scripts/minikconf.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/minikconf.py) +Configuring x86_64-softmmu-config-target.h using configuration +Configuring x86_64-softmmu-config-devices.mak with command +Reading depfile: C:/Users/AMD-RYZEN-PC/qemu/build/meson-private/x86_64-softmmu-config-devices.mak.d +Configuring x86_64-softmmu-config-devices.h using configuration +Program scripts/make-config-poison.sh found: YES (sh C:/Users/AMD-RYZEN-PC/qemu/scripts/make-config-poison.sh) +Run-time dependency capstone found: NO (tried pkgconfig) +Library fdt found: NO +Configuring config-host.h using configuration +Program scripts/hxtool found: YES (sh C:/Users/AMD-RYZEN-PC/qemu/scripts/hxtool) +Program scripts/shaderinclude.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/shaderinclude.py) +Program scripts/qapi-gen.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/qapi-gen.py) +Program scripts/qemu-version.sh found: YES (sh C:/Users/AMD-RYZEN-PC/qemu/scripts/qemu-version.sh) +Program scripts/decodetree.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/decodetree.py) +Program ../scripts/modules/module_block.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/block/../scripts/modules/module_block.py) +Program ../scripts/block-coroutine-wrapper.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/block/../scripts/block-coroutine-wrapper.py) +Program scripts/modinfo-collect.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/modinfo-collect.py) +Program scripts/modinfo-generate.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/modinfo-generate.py) +Program nm found: YES +Program scripts/undefsym.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/undefsym.py) +Program scripts/feature_to_c.sh found: YES (sh C:/Users/AMD-RYZEN-PC/qemu/scripts/feature_to_c.sh) +Compiler for C supports link arguments -fstack-protector-all: YES +Compiler for C supports link arguments -fstack-protector-strong: YES +Compiler for C supports link arguments -Wl,--add-stdcall-alias: YES +Compiler for C supports link arguments -Wl,--enable-stdcall-fixup: YES +Library ole32 found: YES +Library oleaut32 found: YES +Library shlwapi found: YES +Library uuid found: YES +Library intl found: YES +Program windmc found: YES +Program windres found: YES +Program wixl found: NO +Configuring 50-edk2-i386-secure.json using configuration +Configuring 50-edk2-x86_64-secure.json using configuration +Configuring 60-edk2-aarch64.json using configuration +Configuring 60-edk2-arm.json using configuration +Configuring 60-edk2-i386.json using configuration +Configuring 60-edk2-x86_64.json using configuration +Program qemu-keymap found: NO +Program sphinx-build found: NO +Program diff found: YES (C:\Users\AMD-RYZEN-PC\scoop\apps\msys2\2023-03-18\usr\bin/diff.EXE) +Program dbus-daemon found: NO +Found CMake: C:\Users\AMD-RYZEN-PC\scoop\shims/cmake.EXE (3.26.3) +WARNING: CMake Toolchain: Failed to determine CMake compilers state +Run-time dependency gvnc-1.0 found: NO (tried pkgconfig and cmake) +Run-time dependency sysprof-capture-4 found: NO (tried pkgconfig and cmake) +Program initrd-stress.sh found: YES (sh C:/Users/AMD-RYZEN-PC/qemu/tests/migration/initrd-stress.sh) +Program xgettext found: YES (C:\Users\AMD-RYZEN-PC\scoop\apps\msys2\2023-03-18\mingw64\bin/xgettext.EXE) +Program scripts/nsis.py found: YES (C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/nsis.py) +Build targets in project: 516 + +qemu 8.0.0 + + Directories + Install prefix : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu + BIOS directory : share/ + firmware path : share/qemu-firmware + binary directory : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu/. + library directory : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu/lib + module directory : lib/ + libexec directory : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu/libexec + include directory : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu/include + config directory : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu/etc + local state directory : queried at runtime + Doc directory : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu/share/doc + Build directory : C:/Users/AMD-RYZEN-PC/qemu/build + Source path : C:/Users/AMD-RYZEN-PC/qemu + GIT submodules : ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc + + Host binaries + git : git + make : make + python : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe (version: 3.10) + sphinx-build : NO + gdb : /mingw64/bin/gdb-multiarch + iasl : NO + genisoimage : + wixl : NO + smbd : NO + + Configurable features + Documentation : NO + system-mode emulation : YES + user-mode emulation : NO + block layer : YES + Install blobs : YES + module support : NO + fuzzing support : NO + Audio drivers : dsound sdl + Trace backends : log + D-Bus display : NO + QOM debugging : NO + vhost-kernel support : NO + vhost-net support : NO + vhost-user support : NO + vhost-user-crypto support : NO + vhost-user-blk server support: NO + vhost-vdpa support : NO + build guest agent : YES + + Compilation + host CPU : x86_64 + host endianness : little + C compiler : cc -m64 -mcx16 + Host C compiler : cc -m64 -mcx16 + C++ compiler : c++ -m64 -mcx16 + CFLAGS : -g -O2 + CXXFLAGS : -g -O2 + QEMU_CFLAGS : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-pie -no-pie -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong + QEMU_CXXFLAGS : -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-pie -no-pie -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -Wundef -Wwrite-strings -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong + QEMU_LDFLAGS : -fstack-protector-strong -Wl,--no-seh -Wl,--nxcompat -Wl,--dynamicbase -Wl,--high-entropy-va -Wl,--warn-common + profiler : NO + link-time optimization (LTO) : NO + PIE : NO + static build : NO + malloc trim support : NO + membarrier : NO + debug stack usage : NO + mutex debugging : NO + memory allocator : system + avx2 optimization : YES + avx512bw optimization : YES + avx512f optimization : NO + gprof : NO + gcov : NO + thread sanitizer : NO + CFI support : NO + strip binaries : NO + sparse : NO + mingw32 support : YES + + Cross compilers + x86_64 : cc + + Targets and accelerators + KVM support : NO + GVM support : YES + HAX support : YES + HVF support : NO + WHPX support : YES + NVMM support : NO + Xen support : NO + Xen emulation : NO + TCG support : YES + TCG backend : native (x86_64) + TCG plugins : NO + TCG debug enabled : NO + target list : x86_64-softmmu + default devices : YES + out of process emulation : NO + vfio-user server : NO + + Block layer support + coroutine backend : win32 + coroutine pool : YES + Block whitelist (rw) : + Block whitelist (ro) : + Use block whitelist in tools : NO + VirtFS support : NO + Live block migration : YES + replication support : YES + bochs support : YES + cloop support : YES + dmg support : YES + qcow v1 support : YES + vdi support : YES + vvfat support : YES + qed support : YES + parallels support : YES + FUSE exports : NO + VDUSE block exports : NO + + Crypto + TLS priority : NORMAL + GNUTLS support : NO + libgcrypt : NO + nettle : NO + AF_ALG support : NO + rng-none : NO + Linux keyring : NO + + Dependencies + SDL support : YES + SDL image support : YES 2.6.3 + GTK support : YES + pixman : YES 0.42.2 + VTE support : NO + slirp support : YES 4.7.0 + libtasn1 : NO + PAM : NO + iconv support : YES + curses support : YES + virgl support : YES 0.9.1 + blkio support : NO + curl support : NO + Multipath support : NO + PNG support : YES 1.6.39 + VNC support : YES + VNC SASL support : NO + VNC JPEG support : YES 2.1.5.1 + DirectSound support : YES + JACK support : NO + brlapi support : NO + vde support : NO + netmap support : NO + l2tpv3 support : NO + Linux AIO support : NO + Linux io_uring support : NO + ATTR/XATTR support : NO + RDMA support : NO + PVRDMA support : NO + fdt support : internal + libcap-ng support : NO + bpf support : NO + spice protocol support : NO + rbd support : NO + smartcard support : NO + U2F support : NO + libusb : YES 1.0.26 + usb net redir : NO + OpenGL support (epoxy) : YES 1.5.10 + GBM : NO + libiscsi support : NO + libnfs support : NO + QGA VSS support : YES + seccomp support : NO + GlusterFS support : NO + TPM support : NO + libssh support : NO + lzo support : YES + snappy support : NO + bzip2 support : YES + lzfse support : NO + zstd support : YES 1.5.5 + NUMA host support : NO + capstone : NO + libpmem support : NO + libdaxctl support : NO + libudev : NO + FUSE lseek : NO + selinux : NO + libdw : NO + + User defined options + Native files : config-meson.cross + bindir : + prefix : C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/qemu + werror : true + b_pie : false + gtk : enabled + qemu_suffix : + sdl : enabled + vfio_user_server : disabled + whpx : enabled + +Found ninja-1.11.1 at C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/usr/bin/ninja.exe +Running postconf script 'C:/Users/AMD-RYZEN-PC/scoop/apps/msys2/2023-03-18/mingw64/bin/python3.exe C:/Users/AMD-RYZEN-PC/qemu/scripts/symlink-install-tree.py' +``` diff --git a/results/classifier/118/graphic/1636126 b/results/classifier/118/graphic/1636126 new file mode 100644 index 000000000..62fa9c98e --- /dev/null +++ b/results/classifier/118/graphic/1636126 @@ -0,0 +1,86 @@ +graphic: 0.833 +performance: 0.791 +debug: 0.787 +permissions: 0.786 +register: 0.777 +assembly: 0.776 +mistranslation: 0.771 +semantic: 0.759 +peripherals: 0.741 +kernel: 0.734 +boot: 0.723 +files: 0.720 +virtual: 0.719 +socket: 0.715 +architecture: 0.711 +PID: 0.701 +device: 0.699 +user-level: 0.676 +risc-v: 0.675 +network: 0.670 +arm: 0.648 +hypervisor: 0.638 +vnc: 0.602 +TCG: 0.572 +ppc: 0.566 +VMM: 0.498 +KVM: 0.448 +x86: 0.437 +i386: 0.422 + +qemu-system-arm segfaults on "smulbb r7, r5, r5" + +I'll attach a binary that runs fine with qemu-system-arm V2.2.0 but V2.7.0 segfaults. +By stepping through with gdb I found that the segfaults happens when executing the line "smulbb r7, r5, r5" (where r7=0x1, r5=0x12). +I'll also attach a debugger screenshot. + +call and output: + +/opt/qemu-system-arm -M integratorcp -cpu cortex-m3 -semihosting -nographic -monitor null -serial null -no-reboot -kernel 0MFW_SafetyFunctions_ParameteruP1_CUNIT.elf + +------------ CUnit_MFW_SafetyFunctions_Parameter ------------ + + + CUnit - A Unit testing framework for C - Version 2.1-0 + http://cunit.sourceforge.net/ + + +Suite: Suite_MFW_SafetyFunctions_Parameter + Test: MFW_SafetyFunctions_Parameter_PositionLimiter ... Segmentation fault (core dumped) + + + +in the screenshot one can see the assembler line that fails + +Hi. This command line: + +/opt/qemu-system-arm -M integratorcp -cpu cortex-m3 ... + +is wrong. The integratorcp board is not a Cortex-M3 and trying to stick one into it produces something that is not likely to work very well. Please can you either (a) using a board that's expected to support a Cortex-M3, like the lm3s6965evb or lm3s811evb, or (b) using the integratorcp's default CPU if that's what your guest code is supposed to run on. This sort of frankenstein combination is not supported... + +That said, your problem here is that the SMULBB instruction is part of the M profile DSP extension, which is not implemented in the Cortex-M3 (it first appears in the -M4). Not UNDEFing on the DSP instructions in our Cortex-M3 model was a bug in QEMU v2.2 which we have subsequently fixed. + +You should build your guest code to target the CPU you're trying to run it on. + + +Hi Peter! + +Thank you for your help, it works fine with "-M integratprcp -cpu cortex-m4" but I might choose another board as you suggested. +I didn't have in mind that we switched to M4 instruction set. + +Where do I get the information that integratorcp is not good for cortex-M3? +Or better question: where do I get information which machine is good for it? +Actually "-M help" doesn't give me any with M3 (already tried "none" and "virt" without success). +On the other hand I see all cortex variants in the output of "-M integratorcp -cpu help" so I had a good feeling about it... + + + +You're right that we don't document this at all (and the board models don't have any way of restricting the set of things that '-cpu help' lists to only what they support). As a rule of thumb, for any ARM board except 'virt' don't try to use anything except the default CPU. They all model embedded boards which don't have any kind of support for unplugging and replugging CPUs. + +The particular problem with trying to use cortex-m3 on the integratorcp is that there is no NVIC on the integratorcp so if you try to do anything involving the M3's interrupt controller it is likely to blow up or otherwise misbehave. + +Our two M3 boards are the lm3s6965evb and lm3s811evb (they're Stellaris boards). + + +Tried to run cortex-M4 command on M3. + diff --git a/results/classifier/118/graphic/1636770 b/results/classifier/118/graphic/1636770 new file mode 100644 index 000000000..fdaaf17b5 --- /dev/null +++ b/results/classifier/118/graphic/1636770 @@ -0,0 +1,56 @@ +graphic: 0.824 +device: 0.767 +ppc: 0.736 +peripherals: 0.732 +performance: 0.679 +semantic: 0.672 +user-level: 0.637 +mistranslation: 0.601 +architecture: 0.579 +permissions: 0.569 +files: 0.546 +register: 0.541 +debug: 0.533 +vnc: 0.488 +network: 0.470 +boot: 0.442 +socket: 0.439 +x86: 0.401 +risc-v: 0.396 +kernel: 0.392 +arm: 0.390 +hypervisor: 0.385 +virtual: 0.382 +PID: 0.379 +i386: 0.366 +assembly: 0.344 +VMM: 0.333 +TCG: 0.302 +KVM: 0.229 + +mouse wheel works only with -usbdevice tablet + +2.7.0 + +tested with windows 10 + +As a test I tried using the wheel mouse on Mac OS 10.4 running in qemu-system-ppc. Scrolling sort of works. It also causes the mouse pointer to move up or down. That is definitely some kind of error. + +Where the problem could be: +Guest operating system +USB mouse emulation +Front-end + +I'm going to rule out "Guest operating system". I think it could be the emulated USB mouse or the front-end. Maybe even a combination of the two. + +I tried using Windows in QEMU and oddly enough both Windows XP and Windows 2000 did not have a working mouse. Both guests had "-usb -device usb-mouse" in their QEMU command-line. Using usb_del to remove the USB mouse made the mouse in the guest work again. The scroll wheel did work. WordPad's window did scroll, but the mouse pointer also moved up and down just like in Mac OS 10.4. Just to note I am using the Cocoa front-end. I'm guessing you are using SDL. + +The emulated mouse does need some fixing. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to +"Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1644 b/results/classifier/118/graphic/1644 new file mode 100644 index 000000000..392dee068 --- /dev/null +++ b/results/classifier/118/graphic/1644 @@ -0,0 +1,44 @@ +graphic: 0.980 +kernel: 0.975 +virtual: 0.972 +device: 0.950 +x86: 0.930 +architecture: 0.906 +PID: 0.885 +files: 0.864 +boot: 0.858 +permissions: 0.853 +register: 0.849 +performance: 0.842 +socket: 0.823 +vnc: 0.815 +user-level: 0.811 +hypervisor: 0.802 +semantic: 0.801 +debug: 0.779 +i386: 0.773 +risc-v: 0.758 +network: 0.757 +TCG: 0.755 +VMM: 0.726 +peripherals: 0.721 +mistranslation: 0.689 +ppc: 0.664 +assembly: 0.573 +arm: 0.553 +KVM: 0.367 + +qemu 8.0.0 console-gl.c:105: surface_gl_update_texture: Assertion `gls' failed. +Description of problem: +run ubuntu20.04 in virtualBox, and run qemu in this ubuntu. +1. qemu report error at qemu start. +2. qemu-system-x86_64 can't run myOS with 'virtio-gpu-pci -display sdl,gl=on', +3. qemu report error: qemu-system-x86_64: ../ui/console-gl.c:105: surface_gl_update_texture: Assertion `gls' failed. Aborted +Steps to reproduce: +1. run ubuntu20.04 in virtualBox +2. qemu config enabled sdl, virglrenderer, opengl, gtk +3. ./qemu-system-x86_64 -machine q35 -cpu Nehalem -m 1024 -smp 8 -kernel myOS -device virtio-gpu-pci -display sdl,gl=on +4. qemu report error: qemu-system-x86_64: ../ui/console-gl.c:105: surface_gl_update_texture: Assertion `gls' failed. Aborted +Additional information: +qemu-system-x86_64: ../ui/console-gl.c:105: surface_gl_update_texture: Assertion `gls' failed. +Aborted diff --git a/results/classifier/118/graphic/1646 b/results/classifier/118/graphic/1646 new file mode 100644 index 000000000..e596c60aa --- /dev/null +++ b/results/classifier/118/graphic/1646 @@ -0,0 +1,91 @@ +graphic: 0.940 +peripherals: 0.939 +semantic: 0.919 +assembly: 0.915 +register: 0.909 +architecture: 0.905 +user-level: 0.899 +device: 0.897 +performance: 0.892 +permissions: 0.891 +risc-v: 0.890 +arm: 0.871 +debug: 0.865 +mistranslation: 0.862 +PID: 0.854 +boot: 0.844 +ppc: 0.838 +vnc: 0.837 +network: 0.830 +TCG: 0.825 +files: 0.824 +KVM: 0.824 +virtual: 0.821 +hypervisor: 0.812 +VMM: 0.812 +socket: 0.784 +i386: 0.771 +kernel: 0.738 +x86: 0.721 + +fstrim dont work after live migrate +Description of problem: +We have use lvm thin pool and after live migration non-shared storage fstrim cannot free data usage Data% without reboot, after reboot fstim work fine + +``` + LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert + p639937 vm Vwi-aotz-- 30.00g pool 99.35 + +virsh qemu-agent-command p639937 '{"execute":"guest-fstrim"}' +{"return":{"paths":[{"minimum":0,"path":"/","trimmed":0}]}} + +virsh shutdown p639937 +Domain 'p639937' is being shutdown + +virsh start p639937 +Domain 'p639937' started + +virsh qemu-agent-command p639937 '{"execute":"guest-fstrim"}' +{"return":{"paths":[{"minimum":0,"path":"/","trimmed":29178654720}]}} + +lvs|grep p639937 + p639937 vm Vwi-aotz-- 30.00g pool 9.58 +``` + +On source host before migration: +``` + LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert + p639937 vm Vwi-a-tz-- 30.00g pool 9.48 +``` + +migration script +``` +SSH_OPTS='-o StrictHostKeyChecking=no -o PasswordAuthentication=no ' +MIGR_OPTS="--live --copy-storage-all --verbose --persistent --undefinesource" +ssh $SSH_OPTS $HOST -t "[ -b /dev/vm/$ACCT ] || /usr/sbin/lvcreate -V${SIZE}G -T vm/pool -n$ACCT" || f_print_err "Error: creation lvm" +virsh migrate $MIGR_OPTS $ACCT qemu+ssh://$SERV/system tcp://local.$SERV/ || f_print_err "Error on step: virsh migrate" +echo "Waiting for trim start..." +sleep 10 +ssh $SSH_OPTS $HOST -t "/usr/bin/virsh qemu-agent-command $ACCT --timeout 60 '{\"execute\":\"guest-fstrim\"}' >/dev/null 2>&1" +``` + +Disc config: +``` + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='none' io='threads' discard='unmap'/> + <source dev='/dev/vm/p639937'/> + <backingStore/> + <target dev='sda' bus='scsi'/> + <iotune> + <write_bytes_sec>104857600</write_bytes_sec> + <write_bytes_sec_max>524288000</write_bytes_sec_max> + <write_bytes_sec_max_length>120</write_bytes_sec_max_length> + </iotune> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> +``` + +Sometimes trimming working after migration, bit this is very rare. +We have try rescanning disc, drop caches on vm after migration, but didnt help. + +Inside vm's ext4 fs and almalinux 8/ubuntu 20+/debian 10-11 diff --git a/results/classifier/118/graphic/1649042 b/results/classifier/118/graphic/1649042 new file mode 100644 index 000000000..a96149321 --- /dev/null +++ b/results/classifier/118/graphic/1649042 @@ -0,0 +1,80 @@ +graphic: 0.888 +mistranslation: 0.877 +device: 0.834 +architecture: 0.762 +hypervisor: 0.746 +x86: 0.729 +semantic: 0.722 +boot: 0.704 +socket: 0.660 +VMM: 0.656 +user-level: 0.653 +peripherals: 0.651 +ppc: 0.640 +performance: 0.628 +network: 0.617 +PID: 0.550 +arm: 0.534 +permissions: 0.517 +register: 0.512 +virtual: 0.508 +debug: 0.490 +kernel: 0.469 +files: 0.448 +vnc: 0.432 +TCG: 0.359 +risc-v: 0.339 +KVM: 0.281 +assembly: 0.229 +i386: 0.196 + +Ubuntu 16.04.1 LightDM Resolution Not Correct + +My Specs: + +Slackware 14.2 x86_64 > Host +Nvidia GPU GTX660M +nvidia-driver-352.63 +QEMU 2.7.0 + +Ubuntu 16.04.1 x86_64 > Guest +Unity +Xorg nouveau - 1:1.0.12-1build2 + +These are the startup options for Ubuntu: + +qemu-system-x86_64 -drive format=raw,file=ubuntu.img \ +-cpu host \ +--enable-kvm \ +-smp 2 \ +-m 4096 \ +-vga vmware \ +-soundhw ac97 \ +-usbdevice tablet \ +-rtc base=localtime \ +-usbdevice host:0781:5575 + +Unity desktop resolution set for 1440x900. + +I noticed when I come to the login screen to enter my password the LightDM resolution fills my entire desktop. + +I searched online and found this solution; + +cp ~/.config/monitor.xml /var/lib/lightdm/.config + +For now I'm assuming this step should not be needed and the resolution should be correctly detected and set? + +Why are you using "-vga vmware" ? Can't you use "-vga std" instead? Also, now that QEMU 2.8 has been released, could you please test again with this latest version? Thanks! + +Hi I'll just post to here for both issues; + +https://bugs.launchpad.net/qemu/+bug/1649042 + +LOL TYPO here; + +https://bugs.launchpad.net/qemu/+bug/1649040 + +Using virtio it works nice.... + +OK, if it works with -vga virtio, I think we should close this bug as WONTFIX, since the -vga vmware code is pretty much unmaintained as far as I know (if somebody is willing to fix this there, too, feel free to open this bug again). + diff --git a/results/classifier/118/graphic/1649233 b/results/classifier/118/graphic/1649233 new file mode 100644 index 000000000..35a0edab0 --- /dev/null +++ b/results/classifier/118/graphic/1649233 @@ -0,0 +1,55 @@ +graphic: 0.931 +device: 0.885 +virtual: 0.883 +user-level: 0.834 +x86: 0.829 +peripherals: 0.805 +performance: 0.744 +semantic: 0.724 +architecture: 0.720 +hypervisor: 0.689 +VMM: 0.670 +permissions: 0.642 +i386: 0.601 +network: 0.593 +kernel: 0.587 +mistranslation: 0.582 +register: 0.581 +KVM: 0.570 +files: 0.529 +debug: 0.519 +PID: 0.476 +assembly: 0.474 +vnc: 0.462 +boot: 0.444 +ppc: 0.443 +risc-v: 0.441 +socket: 0.427 +arm: 0.375 +TCG: 0.311 + +scrolling does not work once mouse is grabbed + +The title pretty much told it all. It occurs in Windows 10 RS1 on qemu 2.7.0. Interestingly, I can scroll in the guest if the mouse is not grabbed. So using usb-tablet sort of works around it, but if I explicitly grab the mouse with Ctrl+Alt+G, scrolling will also stop working. + +The host is Arch Linux so the qemu build uses gtk(3) for GUI by default. I wanted to test with sdl but it seems sdl support in qemu is sort of broken that I can't even start the virtual machine properly with that. + +Full commands I used: + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -drive file=test.img,format=raw + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -drive file=test.img,format=raw -device nec-usb-xhci -device usb-kbd -device usb-mouse + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -drive file=test.img,format=raw -device nec-usb-xhci -device usb-kbd -device usb-tablet + +Not sure if it is relevant, but there's a HID button device cannot get started in Windows 10 RS1. + +I am also having trouble with this bug. I have QEMU version 2.11.1 on kubuntu. I have the same symptoms as above, and would be willing to assist in troubleshooting. The mouse I am using has two side buttons for forward and back on web-browsing and a scroll wheel with scroll button. I am using QEMU/KVM through Virtual Machine Manager. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to +"Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1651167 b/results/classifier/118/graphic/1651167 new file mode 100644 index 000000000..13bbd0bcd --- /dev/null +++ b/results/classifier/118/graphic/1651167 @@ -0,0 +1,580 @@ +graphic: 0.961 +architecture: 0.950 +permissions: 0.939 +device: 0.930 +register: 0.924 +debug: 0.915 +performance: 0.913 +assembly: 0.900 +arm: 0.899 +user-level: 0.894 +socket: 0.890 +virtual: 0.884 +vnc: 0.866 +TCG: 0.851 +PID: 0.846 +kernel: 0.845 +risc-v: 0.843 +VMM: 0.841 +files: 0.829 +hypervisor: 0.823 +KVM: 0.810 +network: 0.805 +semantic: 0.799 +mistranslation: 0.777 +boot: 0.773 +peripherals: 0.740 +ppc: 0.716 +x86: 0.598 +i386: 0.294 + +hw/ipmi/isa_ipmi_bt.c:283: suspect use of macro ? + +I just had a go at compiling qemu trunk with +llvm trunk. It said: + +hw/ipmi/isa_ipmi_bt.c:283:31: warning: logical not is only applied to the left hand side of this bitwise operator [-Wlogical-not-parentheses] + +Source code is + + IPMI_BT_SET_HBUSY(ib->control_reg, + !IPMI_BT_GET_HBUSY(ib->control_reg)); + +That use of ! causes trouble. The SET and GET +macros are defined as: + +#define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) +#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ + (((v & 1) << IPMI_BT_HBUSY_BIT))) + +I can make the compiler shut up by adding extra () in the last +use of v in the SET macro, like this: + +#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ + ((((v) & 1) << IPMI_BT_HBUSY_BIT))) + +I think this is standard good practice when using macro parameters anyway. + +From: Corey Minyard <email address hidden> + +Macro parameters should almost always have () around them when used. +llvm reported an error on this. + +Reported in https://bugs.launchpad.net/bugs/1651167 + +Signed-off-by: Corey Minyard <email address hidden> +--- + hw/ipmi/isa_ipmi_bt.c | 18 +++++++++--------- + 1 file changed, 9 insertions(+), 9 deletions(-) + +diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +index f036617..8a97314 100644 +--- a/hw/ipmi/isa_ipmi_bt.c ++++ b/hw/ipmi/isa_ipmi_bt.c +@@ -40,37 +40,37 @@ + #define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) + #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) + #define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_WR_BIT))) ++ ((((v) & 1) << IPMI_BT_CLR_WR_BIT))) + + #define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) + #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) + #define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_RD_BIT))) ++ ((((v) & 1) << IPMI_BT_CLR_RD_BIT))) + + #define IPMI_BT_H2B_ATN_MASK (1 << IPMI_BT_H2B_ATN_BIT) + #define IPMI_BT_GET_H2B_ATN(d) (((d) >> IPMI_BT_H2B_ATN_BIT) & 0x1) + #define IPMI_BT_SET_H2B_ATN(d, v) (d) = (((d) & ~IPMI_BT_H2B_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_H2B_ATN_BIT))) ++ ((((v) & 1) << IPMI_BT_H2B_ATN_BIT))) + + #define IPMI_BT_B2H_ATN_MASK (1 << IPMI_BT_B2H_ATN_BIT) + #define IPMI_BT_GET_B2H_ATN(d) (((d) >> IPMI_BT_B2H_ATN_BIT) & 0x1) + #define IPMI_BT_SET_B2H_ATN(d, v) (d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_ATN_BIT))) ++ ((((v) & 1) << IPMI_BT_B2H_ATN_BIT))) + + #define IPMI_BT_SMS_ATN_MASK (1 << IPMI_BT_SMS_ATN_BIT) + #define IPMI_BT_GET_SMS_ATN(d) (((d) >> IPMI_BT_SMS_ATN_BIT) & 0x1) + #define IPMI_BT_SET_SMS_ATN(d, v) (d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_SMS_ATN_BIT))) ++ ((((v) & 1) << IPMI_BT_SMS_ATN_BIT))) + + #define IPMI_BT_HBUSY_MASK (1 << IPMI_BT_HBUSY_BIT) + #define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) + #define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_HBUSY_BIT))) ++ ((((v) & 1) << IPMI_BT_HBUSY_BIT))) + + #define IPMI_BT_BBUSY_MASK (1 << IPMI_BT_BBUSY_BIT) + #define IPMI_BT_GET_BBUSY(d) (((d) >> IPMI_BT_BBUSY_BIT) & 0x1) + #define IPMI_BT_SET_BBUSY(d, v) (d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_BBUSY_BIT))) ++ ((((v) & 1) << IPMI_BT_BBUSY_BIT))) + + + /* Mask register */ +@@ -80,12 +80,12 @@ + #define IPMI_BT_B2H_IRQ_EN_MASK (1 << IPMI_BT_B2H_IRQ_EN_BIT) + #define IPMI_BT_GET_B2H_IRQ_EN(d) (((d) >> IPMI_BT_B2H_IRQ_EN_BIT) & 0x1) + #define IPMI_BT_SET_B2H_IRQ_EN(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) ++ ((((v) & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) + + #define IPMI_BT_B2H_IRQ_MASK (1 << IPMI_BT_B2H_IRQ_BIT) + #define IPMI_BT_GET_B2H_IRQ(d) (((d) >> IPMI_BT_B2H_IRQ_BIT) & 0x1) + #define IPMI_BT_SET_B2H_IRQ(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_BIT))) ++ ((((v) & 1) << IPMI_BT_B2H_IRQ_BIT))) + + typedef struct IPMIBT { + IPMIBmc *bmc; +-- +2.7.4 + + + +On 12/22/2016 08:30 AM, <email address hidden> wrote: +> From: Corey Minyard <email address hidden> +> +> Macro parameters should almost always have () around them when used. +> llvm reported an error on this. +> +> Reported in https://bugs.launchpad.net/bugs/1651167 +> +> Signed-off-by: Corey Minyard <email address hidden> +> --- +> hw/ipmi/isa_ipmi_bt.c | 18 +++++++++--------- +> 1 file changed, 9 insertions(+), 9 deletions(-) +> +> diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +> index f036617..8a97314 100644 +> --- a/hw/ipmi/isa_ipmi_bt.c +> +++ b/hw/ipmi/isa_ipmi_bt.c +> @@ -40,37 +40,37 @@ +> #define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) +> #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) +> #define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ + +Still under-parenthesized, if the result of IPMI_BT_SET_CLR_WR() is used +in any larger expression; + +> - (((v & 1) << IPMI_BT_CLR_WR_BIT))) +> + ((((v) & 1) << IPMI_BT_CLR_WR_BIT))) + +and at the same time, you (still) have a redundant set on the second line. + +Better would be: + +((d) = (((d) & ~IPMI_BD_CLR_WR_MASK) | \ + (((v) & 1) << IPMI_BT_CLR_WR_BIT))) + +> +> #define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) +> #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) +> #define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +> - (((v & 1) << IPMI_BT_CLR_RD_BIT))) +> + ((((v) & 1) << IPMI_BT_CLR_RD_BIT))) + +and again, throughout the patch. + + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +On 12/22/2016 09:01 AM, Eric Blake wrote: +> On 12/22/2016 08:30 AM, <email address hidden> wrote: +>> From: Corey Minyard <email address hidden> +>> +>> Macro parameters should almost always have () around them when used. +>> llvm reported an error on this. +>> +>> Reported in https://bugs.launchpad.net/bugs/1651167 +>> +>> Signed-off-by: Corey Minyard <email address hidden> +>> --- +>> hw/ipmi/isa_ipmi_bt.c | 18 +++++++++--------- +>> 1 file changed, 9 insertions(+), 9 deletions(-) +>> +>> diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +>> index f036617..8a97314 100644 +>> --- a/hw/ipmi/isa_ipmi_bt.c +>> +++ b/hw/ipmi/isa_ipmi_bt.c +>> @@ -40,37 +40,37 @@ +>> #define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) +>> #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) +>> #define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ +> Still under-parenthesized, if the result of IPMI_BT_SET_CLR_WR() is used +> in any larger expression; + +I wasn't thinking about this being used in a larger expression, but it +should be protected, +I suppose. I'll re-submit with that fixed and the extra () removed. + +Thanks, + +-corey + +>> - (((v & 1) << IPMI_BT_CLR_WR_BIT))) +>> + ((((v) & 1) << IPMI_BT_CLR_WR_BIT))) +> and at the same time, you (still) have a redundant set on the second line. +> +> Better would be: +> +> ((d) = (((d) & ~IPMI_BD_CLR_WR_MASK) | \ +> (((v) & 1) << IPMI_BT_CLR_WR_BIT))) +> +>> +>> #define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) +>> #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) +>> #define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +>> - (((v & 1) << IPMI_BT_CLR_RD_BIT))) +>> + ((((v) & 1) << IPMI_BT_CLR_RD_BIT))) +> and again, throughout the patch. +> +> + + + +From: Corey Minyard <email address hidden> + +Macro parameters should almost always have () around them when used. +llvm reported an error on this. + +Remove redundant parenthesis and put parenthesis around the entire +macros with assignments in case they are used in an expression. + +Remove some unused macros. + +Reported in https://bugs.launchpad.net/bugs/1651167 + +Signed-off-by: Corey Minyard <email address hidden> +--- + hw/ipmi/isa_ipmi_bt.c | 34 ++++++++++++---------------------- + 1 file changed, 12 insertions(+), 22 deletions(-) + +Changes in v2: + * Put parenthesis around macros that had assignment in them. + * Removed some redundant parenthesis. + * Removed some macros that were not used. + +diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +index f036617..68bf5cd 100644 +--- a/hw/ipmi/isa_ipmi_bt.c ++++ b/hw/ipmi/isa_ipmi_bt.c +@@ -37,40 +37,30 @@ + #define IPMI_BT_HBUSY_BIT 6 + #define IPMI_BT_BBUSY_BIT 7 + +-#define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) + #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) +-#define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_WR_BIT))) + +-#define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) + #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) +-#define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_RD_BIT))) + +-#define IPMI_BT_H2B_ATN_MASK (1 << IPMI_BT_H2B_ATN_BIT) + #define IPMI_BT_GET_H2B_ATN(d) (((d) >> IPMI_BT_H2B_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_H2B_ATN(d, v) (d) = (((d) & ~IPMI_BT_H2B_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_H2B_ATN_BIT))) + + #define IPMI_BT_B2H_ATN_MASK (1 << IPMI_BT_B2H_ATN_BIT) + #define IPMI_BT_GET_B2H_ATN(d) (((d) >> IPMI_BT_B2H_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_ATN(d, v) (d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_ATN_BIT))) ++#define IPMI_BT_SET_B2H_ATN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ ++ (((v) & 1) << IPMI_BT_B2H_ATN_BIT))) + + #define IPMI_BT_SMS_ATN_MASK (1 << IPMI_BT_SMS_ATN_BIT) + #define IPMI_BT_GET_SMS_ATN(d) (((d) >> IPMI_BT_SMS_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_SMS_ATN(d, v) (d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_SMS_ATN_BIT))) ++#define IPMI_BT_SET_SMS_ATN(d, v) ((d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ ++ (((v) & 1) << IPMI_BT_SMS_ATN_BIT))) + + #define IPMI_BT_HBUSY_MASK (1 << IPMI_BT_HBUSY_BIT) + #define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) +-#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_HBUSY_BIT))) ++#define IPMI_BT_SET_HBUSY(d, v) ((d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ ++ (((v) & 1) << IPMI_BT_HBUSY_BIT))) + + #define IPMI_BT_BBUSY_MASK (1 << IPMI_BT_BBUSY_BIT) +-#define IPMI_BT_GET_BBUSY(d) (((d) >> IPMI_BT_BBUSY_BIT) & 0x1) +-#define IPMI_BT_SET_BBUSY(d, v) (d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_BBUSY_BIT))) ++#define IPMI_BT_SET_BBUSY(d, v) ((d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ ++ (((v) & 1) << IPMI_BT_BBUSY_BIT))) + + + /* Mask register */ +@@ -79,13 +69,13 @@ + + #define IPMI_BT_B2H_IRQ_EN_MASK (1 << IPMI_BT_B2H_IRQ_EN_BIT) + #define IPMI_BT_GET_B2H_IRQ_EN(d) (((d) >> IPMI_BT_B2H_IRQ_EN_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_IRQ_EN(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) ++#define IPMI_BT_SET_B2H_IRQ_EN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) |\ ++ (((v) & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) + + #define IPMI_BT_B2H_IRQ_MASK (1 << IPMI_BT_B2H_IRQ_BIT) + #define IPMI_BT_GET_B2H_IRQ(d) (((d) >> IPMI_BT_B2H_IRQ_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_IRQ(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_BIT))) ++#define IPMI_BT_SET_B2H_IRQ(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ ++ (((v) & 1) << IPMI_BT_B2H_IRQ_BIT))) + + typedef struct IPMIBT { + IPMIBmc *bmc; +-- +2.7.4 + + + +On 12/22/2016 01:18 PM, <email address hidden> wrote: +> From: Corey Minyard <email address hidden> +> +> Macro parameters should almost always have () around them when used. +> llvm reported an error on this. +> +> Remove redundant parenthesis and put parenthesis around the entire +> macros with assignments in case they are used in an expression. +> +> Remove some unused macros. +> +> Reported in https://bugs.launchpad.net/bugs/1651167 +> +> Signed-off-by: Corey Minyard <email address hidden> +> --- +> hw/ipmi/isa_ipmi_bt.c | 34 ++++++++++++---------------------- +> 1 file changed, 12 insertions(+), 22 deletions(-) + +Reviewed-by: Eric Blake <email address hidden> + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +From: Corey Minyard <email address hidden> + +Macro parameters should almost always have () around them when used. +llvm reported an error on this. + +Remove redundant parenthesis and put parenthesis around the entire +macros with assignments in case they are used in an expression. + +Remove some unused macros. + +Reported in https://bugs.launchpad.net/bugs/1651167 + +Signed-off-by: Corey Minyard <email address hidden> +Reviewed-by: Eric Blake <email address hidden> +--- + hw/ipmi/isa_ipmi_bt.c | 34 ++++++++++++---------------------- + 1 file changed, 12 insertions(+), 22 deletions(-) + +Changed in v3: + * Add Eric's reviewed-by. Thanks! + +Changes in v2: + * Put parenthesis around macros that had assignment in them. + * Removed some redundant parenthesis. + * Removed some macros that were not used. + +diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +index f036617..68bf5cd 100644 +--- a/hw/ipmi/isa_ipmi_bt.c ++++ b/hw/ipmi/isa_ipmi_bt.c +@@ -37,40 +37,30 @@ + #define IPMI_BT_HBUSY_BIT 6 + #define IPMI_BT_BBUSY_BIT 7 + +-#define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) + #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) +-#define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_WR_BIT))) + +-#define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) + #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) +-#define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_RD_BIT))) + +-#define IPMI_BT_H2B_ATN_MASK (1 << IPMI_BT_H2B_ATN_BIT) + #define IPMI_BT_GET_H2B_ATN(d) (((d) >> IPMI_BT_H2B_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_H2B_ATN(d, v) (d) = (((d) & ~IPMI_BT_H2B_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_H2B_ATN_BIT))) + + #define IPMI_BT_B2H_ATN_MASK (1 << IPMI_BT_B2H_ATN_BIT) + #define IPMI_BT_GET_B2H_ATN(d) (((d) >> IPMI_BT_B2H_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_ATN(d, v) (d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_ATN_BIT))) ++#define IPMI_BT_SET_B2H_ATN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ ++ (((v) & 1) << IPMI_BT_B2H_ATN_BIT))) + + #define IPMI_BT_SMS_ATN_MASK (1 << IPMI_BT_SMS_ATN_BIT) + #define IPMI_BT_GET_SMS_ATN(d) (((d) >> IPMI_BT_SMS_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_SMS_ATN(d, v) (d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_SMS_ATN_BIT))) ++#define IPMI_BT_SET_SMS_ATN(d, v) ((d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ ++ (((v) & 1) << IPMI_BT_SMS_ATN_BIT))) + + #define IPMI_BT_HBUSY_MASK (1 << IPMI_BT_HBUSY_BIT) + #define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) +-#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_HBUSY_BIT))) ++#define IPMI_BT_SET_HBUSY(d, v) ((d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ ++ (((v) & 1) << IPMI_BT_HBUSY_BIT))) + + #define IPMI_BT_BBUSY_MASK (1 << IPMI_BT_BBUSY_BIT) +-#define IPMI_BT_GET_BBUSY(d) (((d) >> IPMI_BT_BBUSY_BIT) & 0x1) +-#define IPMI_BT_SET_BBUSY(d, v) (d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_BBUSY_BIT))) ++#define IPMI_BT_SET_BBUSY(d, v) ((d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ ++ (((v) & 1) << IPMI_BT_BBUSY_BIT))) + + + /* Mask register */ +@@ -79,13 +69,13 @@ + + #define IPMI_BT_B2H_IRQ_EN_MASK (1 << IPMI_BT_B2H_IRQ_EN_BIT) + #define IPMI_BT_GET_B2H_IRQ_EN(d) (((d) >> IPMI_BT_B2H_IRQ_EN_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_IRQ_EN(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) ++#define IPMI_BT_SET_B2H_IRQ_EN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) |\ ++ (((v) & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) + + #define IPMI_BT_B2H_IRQ_MASK (1 << IPMI_BT_B2H_IRQ_BIT) + #define IPMI_BT_GET_B2H_IRQ(d) (((d) >> IPMI_BT_B2H_IRQ_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_IRQ(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_BIT))) ++#define IPMI_BT_SET_B2H_IRQ(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ ++ (((v) & 1) << IPMI_BT_B2H_IRQ_BIT))) + + typedef struct IPMIBT { + IPMIBmc *bmc; +-- +2.7.4 + + + +Ping - did this ever get applied? + +On 12/23/2016 08:07 AM, <email address hidden> wrote: +> From: Corey Minyard <email address hidden> +> +> Macro parameters should almost always have () around them when used. +> llvm reported an error on this. +> +> Remove redundant parenthesis and put parenthesis around the entire +> macros with assignments in case they are used in an expression. +> +> Remove some unused macros. +> +> Reported in https://bugs.launchpad.net/bugs/1651167 +> +> Signed-off-by: Corey Minyard <email address hidden> +> Reviewed-by: Eric Blake <email address hidden> +> --- +> hw/ipmi/isa_ipmi_bt.c | 34 ++++++++++++---------------------- +> 1 file changed, 12 insertions(+), 22 deletions(-) +> +> Changed in v3: +> * Add Eric's reviewed-by. Thanks! +> +> Changes in v2: +> * Put parenthesis around macros that had assignment in them. +> * Removed some redundant parenthesis. +> * Removed some macros that were not used. +> +> diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +> index f036617..68bf5cd 100644 +> --- a/hw/ipmi/isa_ipmi_bt.c +> +++ b/hw/ipmi/isa_ipmi_bt.c +> @@ -37,40 +37,30 @@ +> #define IPMI_BT_HBUSY_BIT 6 +> #define IPMI_BT_BBUSY_BIT 7 +> +> -#define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) +> #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) +> -#define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ +> - (((v & 1) << IPMI_BT_CLR_WR_BIT))) +> +> -#define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) +> #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) +> -#define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +> - (((v & 1) << IPMI_BT_CLR_RD_BIT))) +> +> -#define IPMI_BT_H2B_ATN_MASK (1 << IPMI_BT_H2B_ATN_BIT) +> #define IPMI_BT_GET_H2B_ATN(d) (((d) >> IPMI_BT_H2B_ATN_BIT) & 0x1) +> -#define IPMI_BT_SET_H2B_ATN(d, v) (d) = (((d) & ~IPMI_BT_H2B_ATN_MASK) | \ +> - (((v & 1) << IPMI_BT_H2B_ATN_BIT))) +> +> #define IPMI_BT_B2H_ATN_MASK (1 << IPMI_BT_B2H_ATN_BIT) +> #define IPMI_BT_GET_B2H_ATN(d) (((d) >> IPMI_BT_B2H_ATN_BIT) & 0x1) +> -#define IPMI_BT_SET_B2H_ATN(d, v) (d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ +> - (((v & 1) << IPMI_BT_B2H_ATN_BIT))) +> +#define IPMI_BT_SET_B2H_ATN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ +> + (((v) & 1) << IPMI_BT_B2H_ATN_BIT))) +> +> #define IPMI_BT_SMS_ATN_MASK (1 << IPMI_BT_SMS_ATN_BIT) +> #define IPMI_BT_GET_SMS_ATN(d) (((d) >> IPMI_BT_SMS_ATN_BIT) & 0x1) +> -#define IPMI_BT_SET_SMS_ATN(d, v) (d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ +> - (((v & 1) << IPMI_BT_SMS_ATN_BIT))) +> +#define IPMI_BT_SET_SMS_ATN(d, v) ((d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ +> + (((v) & 1) << IPMI_BT_SMS_ATN_BIT))) +> +> #define IPMI_BT_HBUSY_MASK (1 << IPMI_BT_HBUSY_BIT) +> #define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) +> -#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ +> - (((v & 1) << IPMI_BT_HBUSY_BIT))) +> +#define IPMI_BT_SET_HBUSY(d, v) ((d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ +> + (((v) & 1) << IPMI_BT_HBUSY_BIT))) +> +> #define IPMI_BT_BBUSY_MASK (1 << IPMI_BT_BBUSY_BIT) +> -#define IPMI_BT_GET_BBUSY(d) (((d) >> IPMI_BT_BBUSY_BIT) & 0x1) +> -#define IPMI_BT_SET_BBUSY(d, v) (d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ +> - (((v & 1) << IPMI_BT_BBUSY_BIT))) +> +#define IPMI_BT_SET_BBUSY(d, v) ((d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ +> + (((v) & 1) << IPMI_BT_BBUSY_BIT))) +> +> +> /* Mask register */ +> @@ -79,13 +69,13 @@ +> +> #define IPMI_BT_B2H_IRQ_EN_MASK (1 << IPMI_BT_B2H_IRQ_EN_BIT) +> #define IPMI_BT_GET_B2H_IRQ_EN(d) (((d) >> IPMI_BT_B2H_IRQ_EN_BIT) & 0x1) +> -#define IPMI_BT_SET_B2H_IRQ_EN(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) | \ +> - (((v & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) +> +#define IPMI_BT_SET_B2H_IRQ_EN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) |\ +> + (((v) & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) +> +> #define IPMI_BT_B2H_IRQ_MASK (1 << IPMI_BT_B2H_IRQ_BIT) +> #define IPMI_BT_GET_B2H_IRQ(d) (((d) >> IPMI_BT_B2H_IRQ_BIT) & 0x1) +> -#define IPMI_BT_SET_B2H_IRQ(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ +> - (((v & 1) << IPMI_BT_B2H_IRQ_BIT))) +> +#define IPMI_BT_SET_B2H_IRQ(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ +> + (((v) & 1) << IPMI_BT_B2H_IRQ_BIT))) +> +> typedef struct IPMIBT { +> IPMIBmc *bmc; +> + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=cb9a05a4f169347f85 + diff --git a/results/classifier/118/graphic/1653 b/results/classifier/118/graphic/1653 new file mode 100644 index 000000000..af88af966 --- /dev/null +++ b/results/classifier/118/graphic/1653 @@ -0,0 +1,50 @@ +graphic: 0.955 +vnc: 0.917 +performance: 0.885 +device: 0.811 +network: 0.786 +virtual: 0.775 +debug: 0.713 +semantic: 0.704 +hypervisor: 0.654 +PID: 0.625 +VMM: 0.605 +mistranslation: 0.587 +boot: 0.562 +architecture: 0.542 +i386: 0.534 +socket: 0.501 +risc-v: 0.462 +kernel: 0.456 +x86: 0.454 +files: 0.452 +user-level: 0.443 +peripherals: 0.414 +ppc: 0.375 +permissions: 0.374 +register: 0.299 +TCG: 0.289 +arm: 0.261 +KVM: 0.228 +assembly: 0.095 + +qemu uses uefi to install the redhad6.0 VM, use the vnc connect it which is stuck +Description of problem: +I want to use uefi(udk2-->ovmf.fd) to install redhad6.0, but after I enter uefi and start up, I cannot use vnc to connect to it,The screen is black or often stuck, nor can I use the console of other pages, or it is a special slow to be able to use it. It's sure that the virtual machine is not crash. Anad the same operation is normal for redhad6.1 systems. +Steps to reproduce: +1.compile udk2 generate ovmf.fd +compile config: + +make -C BaseTools/Source/C + +./OvmfPkg/build.sh -D DEBUG_ON_SERIAL_PORT=true + + +2.run qemu with "-bios /bin/OVMF.fd" + + +3.use vnc to connet it + + + +The screen is stuck can't handle it. diff --git a/results/classifier/118/graphic/1655764 b/results/classifier/118/graphic/1655764 new file mode 100644 index 000000000..80c4549ed --- /dev/null +++ b/results/classifier/118/graphic/1655764 @@ -0,0 +1,58 @@ +graphic: 0.825 +mistranslation: 0.818 +device: 0.814 +risc-v: 0.806 +semantic: 0.800 +x86: 0.798 +performance: 0.766 +architecture: 0.714 +files: 0.705 +socket: 0.692 +vnc: 0.691 +VMM: 0.690 +ppc: 0.686 +permissions: 0.680 +boot: 0.662 +user-level: 0.661 +network: 0.656 +kernel: 0.644 +i386: 0.619 +virtual: 0.616 +PID: 0.615 +TCG: 0.611 +register: 0.588 +peripherals: 0.548 +hypervisor: 0.548 +arm: 0.487 +debug: 0.474 +KVM: 0.417 +assembly: 0.350 + +qemu-img convert -c compression can't decompress + +Used -c compression option of qemu-img convert to compress qcow2, +then libvirt mount for compressed image don't work as well as decompression also +not working, tried glib-deflate to decompress + +Used openssl zlib -d < compressedfile but that also not working + +When tried zlib-flate -uncompress < cirros-0.3.4-x86_64-disk.img, +getting below error + +data: incorrect header check + +Which version of QEMU (or rather qemu-img) are you using? + +qemu-img version 2.1.2, Copyright (c) 2004-2008 Fabrice Bellard + +When reporting bugs, please always use the latest version of QEMU, old versions like 2.1 are not supported anymore. I just also noticed that Stefan Hajnoczi replied to the bug mail on the qemu-devel mailing list (see https://<email address hidden>/msg422186.html) - seems like the bridge did not mirror this to the bug tracker: + +"QEMU image compression uses the compression feature available in some + disk image formats (like qcow2). This is not the same as compressing a + file with gzip, bzip2, or similar tools. + Therefore this error is expected and not a bug." + +Yes used qcow2 format only when compressing, I don't think due to older version problem + +When converting qcow2 with -c option, then after not able to boot VM with compressed qcow2 image + diff --git a/results/classifier/118/graphic/1656676 b/results/classifier/118/graphic/1656676 new file mode 100644 index 000000000..5fb7e347c --- /dev/null +++ b/results/classifier/118/graphic/1656676 @@ -0,0 +1,55 @@ +graphic: 0.804 +vnc: 0.758 +ppc: 0.734 +architecture: 0.734 +device: 0.691 +semantic: 0.676 +performance: 0.644 +PID: 0.574 +TCG: 0.524 +mistranslation: 0.518 +i386: 0.507 +debug: 0.490 +network: 0.466 +VMM: 0.465 +x86: 0.433 +register: 0.432 +hypervisor: 0.411 +user-level: 0.408 +risc-v: 0.393 +assembly: 0.356 +kernel: 0.350 +permissions: 0.322 +peripherals: 0.313 +socket: 0.312 +files: 0.304 +arm: 0.277 +virtual: 0.270 +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/118/graphic/1659 b/results/classifier/118/graphic/1659 new file mode 100644 index 000000000..46ab58159 --- /dev/null +++ b/results/classifier/118/graphic/1659 @@ -0,0 +1,57 @@ +graphic: 0.928 +x86: 0.911 +architecture: 0.837 +arm: 0.803 +vnc: 0.719 +performance: 0.699 +debug: 0.699 +device: 0.694 +files: 0.636 +PID: 0.620 +semantic: 0.590 +virtual: 0.555 +permissions: 0.533 +register: 0.450 +user-level: 0.433 +ppc: 0.433 +boot: 0.400 +hypervisor: 0.391 +risc-v: 0.390 +socket: 0.384 +TCG: 0.330 +network: 0.330 +mistranslation: 0.315 +VMM: 0.262 +peripherals: 0.172 +i386: 0.154 +kernel: 0.127 +assembly: 0.064 +KVM: 0.041 + +x86 vm fails to stop on Darwin aarch64 when qemu compiled with -O1/-O2 +Description of problem: +When compiled with `-O2` or `-O1` qemu process hangs on full VM stopping on macOS aarch64 host if `shutdown -P now` initiated from guest system. +Steps to reproduce: +1. Compile latest qemu version with -O2 (default value) or -O1 passed +2. Run qemu-system-x86_64 with ubuntu image, e.g. https://cloud-images.ubuntu.com/focal/20230215/focal-server-cloudimg-amd64.img and custom cloud-init (for user/password authentication) +3. Wait until image is loaded, connect via vnc or provide login/password in stdio +4. Initiate shutdown with `sudo shutdown -P now` +5. See that VM indefinitely shutdowns +6. Kill VM from host system with kill -9 <qemu-system-x86_64-process-pid> +7. Recompile qemu with -O0 +8. Repeat steps 2-4 +9. See that vm successfully stopped, and qemu process exited with code 0 +Additional information: +I've created thread dump from activity monitor with threads which qemu hanging on, attached below +[sample-qemu-system-x86_64.txt](/uploads/119b89b7f55f4374acb9ae1f9dc2e517/sample-qemu-system-x86_64.txt) + +Probably there is some compiler optimisation which prevents qemu threads from receive shutdown signal or appropriate notification from another threads. + +The compiler version with which qemu is built: +```bash +% cc --version +Apple clang version 14.0.3 (clang-1403.0.22.14.1) +Target: arm64-apple-darwin22.4.0 +Thread model: posix +InstalledDir: /Library/Developer/CommandLineTools/usr/bin +``` diff --git a/results/classifier/118/graphic/1660946 b/results/classifier/118/graphic/1660946 new file mode 100644 index 000000000..dd304181c --- /dev/null +++ b/results/classifier/118/graphic/1660946 @@ -0,0 +1,283 @@ +graphic: 0.801 +debug: 0.767 +risc-v: 0.754 +assembly: 0.746 +register: 0.741 +device: 0.738 +permissions: 0.732 +semantic: 0.719 +PID: 0.714 +TCG: 0.702 +performance: 0.701 +files: 0.700 +virtual: 0.697 +vnc: 0.689 +user-level: 0.688 +architecture: 0.675 +boot: 0.671 +mistranslation: 0.669 +ppc: 0.663 +peripherals: 0.647 +socket: 0.642 +arm: 0.637 +network: 0.625 +hypervisor: 0.577 +kernel: 0.573 +VMM: 0.547 +KVM: 0.544 +i386: 0.355 +x86: 0.285 + +[nested] virt-install falls to SLOF + + +[nested] virt-install falls to SLOF: after starting installer (ISO/CDROM), it crashes w/ a kernel panic due to an HTM (Hardware Transactional Memory) exception. + +Scenario: +Host=Ubuntu 16.04 Xenial (Ubuntu KVM ppc64el POWER8E 8247-22L) +Guest=Ubuntu 16.04 Xenial (Ubuntu Xenial Cloud Image QCOW2) +Nested=Ubuntu 16.04 Xenial (Ubuntu Xenial Server ISO *or* NetInstall mini.iso) + +Inside Guest (1st level), run virt-install as shown below to reproduce the bug. + +Facts: + * ISO images (from both Server or netinstall mini.iso) fail to boot on xenial/yakkety + * Cloud image (xenial/yakkety/zesty) on nested virt boots fine, the login prompt is seen. + * Reproducible with Xenial and Yakkety + * NOT reproducible with Zesty (Installer menu starts just normally) + * virtio-scsi, virtio-net and virtio-blk modules are seen in zesty. Only virtio-scsi is seen on xenial/yakkety (-net and -blk are built-in modules?) + * kvm-pr is loaded for all tested scenarios + * This patch[1] rings a bell, however, it doesn't explain how cloud images boot just fine and don't hit the bug, since the kernel used in the cloud images also enable HTM[2]. + +[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-April/141292.html + +[2] grep TRANSA /boot/config-4.8.0-26-generic +CONFIG_PPC_TRANSACTIONAL_MEM=y + + +# cat virt-inst.sh +virt-install --virt-type=kvm --cpu=host --name=nested-xenial --controller type=scsi,model=virtio-scsi --graphics none --console pty,target_type=serial --disk path=/home/nested-xenial.qcow2,size=20 --vcpus=4 --ram=4096 --os-type=linux --os-variant ubuntu16.04 --network bridge=virbr0,model=virtio --cdrom=$1 + + +# ./virt-inst.sh ubuntu-16.04-server-ppc64el.iso +WARNING CDROM media does not print to the text console by default, so you likely will not see text install output. You might want to use --location. See the man page for examples of using --location with CDROM media + +Starting install... +Creating domain... | 0 B 00:00:00 +Connected to domain nested-xenial +Escape character is ^] +Populating /vdevice methods +Populating /vdevice/vty@30000000 +Populating /vdevice/nvram@71000000 +Populating /pci@800000020000000 + 00 2800 (D) : 1af4 1002 unknown-legacy-device* + 00 2000 (D) : 1af4 1001 virtio [ block ] + 00 1800 (D) : 106b 003f serial bus [ usb-ohci ] + 00 1000 (D) : 1af4 1004 virtio [ scsi ] +Populating /pci@800000020000000/scsi@2 + SCSI: Looking for devices + 100000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" + 00 0800 (D) : 10ec 8139 network [ ethernet ] +No NVRAM common partition, re-initializing... +Scanning USB + OHCI: initializing +Using default console: /vdevice/vty@30000000 + + Welcome to Open Firmware + + Copyright (c) 2004, 2011 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + + +Trying to load: from: /pci@800000020000000/scsi@2/disk@100000000000000 ... Successfully loaded + + GNU GRUB version 2.02~beta2-36ubuntu3 + + +----------------------------------------------------------------------------+ + |*Install | + | Rescue mode | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + +----------------------------------------------------------------------------+ + + Use the ^ and v keys to select which entry is highlighted. + Press enter to boot the selected OS, `e' to edit the commands + before booting or `c' for a command-line. + + +OF stdout device is: /vdevice/vty@30000000 +Preparing to boot Linux version 4.4.0-21-generic (buildd@bos01-ppc64el-017) (gcc version 5.3.1 20160413 (Ubuntu/IBM 5.3.1-14ubuntu2) ) #37-Ubuntu SMP Mon Apr 18 18:30:22 UTC 2016 (Ubuntu 4.4.0-21.37-generic 4.4.6) +Detected machine type: 0000000000000101 +Max number of cores passed to firmware: 2048 (NR_CPUS = 2048) +Calling ibm,client-architecture-support... done +command line: BOOT_IMAGE=/install/vmlinux tasks=standard pkgsel/language-pack-patterns= pkgsel/install-language-support=false --- quiet +memory layout at init: + memory_limit : 0000000000000000 (16 MB aligned) + alloc_bottom : 0000000004640000 + alloc_top : 0000000030000000 + alloc_top_hi : 0000000100000000 + rmo_top : 0000000030000000 + ram_top : 0000000100000000 +instantiating rtas at 0x000000002fff0000... done +prom_hold_cpus: skipped +copying OF device tree... +Building dt strings... +Building dt structure... +Device tree strings 0x0000000004650000 -> 0x0000000004650a5b +Device tree struct 0x0000000004660000 -> 0x0000000004670000 +Quiescing Open Firmware ... +Booting Linux via __start() ... + -> smp_release_cpus() +spinning_secondaries = 3 + <- smp_release_cpus() + <- setup_system() +Linux ppc64le +#37-Ubuntu SMP M[ 2.155665] Facility 'TM' unavailable, exception at 0x3fff9f3d8644, MSR=b00000014280f033 +[ 2.161582] Facility 'TM' unavailable, exception at 0x3fff8a488644, MSR=b00000014280f033 +[ 2.168973] Facility 'TM' unavailable, exception at 0x3fffb2df8644, MSR=b00000014280f033 +[ 2.174818] Facility 'TM' unavailable, exception at 0x3fff902f8644, MSR=b00000014280f033 +[ 2.180887] Facility 'TM' unavailable, exception at 0x3fff84728644, MSR=b00000014280f033 +[ 2.186023] Facility 'TM' unavailable, exception at 0x3fff8f1f8644, MSR=b00000014280f033 +[ 2.193073] Facility 'TM' unavailable, exception at 0x3fffa8ecfe30, MSR=b00000014280f033 +[ 2.193697] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 +[ 2.193697] +[ 2.193751] CPU: 3 PID: 1 Comm: init Not tainted 4.4.0-21-generic #37-Ubuntu +[ 2.193788] Call Trace: +[ 2.193826] [c0000000fea83a50] [c000000000aedc1c] dump_stack+0xb0/0xf0 (unreliable) +[ 2.193868] [c0000000fea83a90] [c000000000ae9e50] panic+0x100/0x2c0 +[ 2.193914] [c0000000fea83b20] [c0000000000bd474] do_exit+0xc24/0xc30 +[ 2.193945] [c0000000fea83be0] [c0000000000bd564] do_group_exit+0x64/0x100 +[ 2.193979] [c0000000fea83c20] [c0000000000ce9cc] get_signal+0x55c/0x7b0 +[ 2.194012] [c0000000fea83d10] [c000000000017424] do_signal+0x54/0x2b0 +[ 2.194043] [c0000000fea83e00] [c00000000001787c] do_notify_resume+0xbc/0xd0 +[ 2.194072] [c0000000fea83e30] [c000000000009838] ret_from_except_lite+0x64/0x68 + +Domain creation completed. +Restarting guest. +Connected to domain nested-xenial +Escape character is ^] +Populating /vdevice methods +Populating /vdevice/vty@30000000 +Populating /vdevice/nvram@71000000 +Populating /pci@800000020000000 + 00 2800 (D) : 1af4 1002 unknown-legacy-device* + 00 2000 (D) : 1af4 1001 virtio [ block ] + 00 1800 (D) : 106b 003f serial bus [ usb-ohci ] + 00 1000 (D) : 1af4 1004 virtio [ scsi ] +Populating /pci@800000020000000/scsi@2 + SCSI: Looking for devices + 100000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" + 00 0800 (D) : 10ec 8139 network [ ethernet ] +No NVRAM common partition, re-initializing... +Scanning USB + OHCI: initializing +Using default console: /vdevice/vty@30000000 + + Welcome to Open Firmware + + Copyright (c) 2004, 2011 IBM Corporation All rights reserved. + This program and the accompanying materials are made available + under the terms of the BSD License available at + http://www.opensource.org/licenses/bsd-license.php + + +Trying to load: from: /pci@800000020000000/scsi@4 ... +E3404: Not a bootable device! +Trying to load: from: HALT ... +E3405: No such device + +E3407: Load failed + + ..`. .. ....... .. ...... ....... + ..`...`''.`'. .''``````..''. .`''```''`. `''`````` + .`` .:' ': `''..... .''. ''` .''..''....... + ``.':.';. ``````''`.''. .''. ''``''`````'` + ``.':':` .....`''.`'`...... `'`.....`''.`'` + .`.`'`` .'`'`````. ``'''''' ``''`'''`. `'` + Type 'boot' and press return to continue booting the system. + Type 'reset-all' and press return to reboot the system. + + +Ready! +0 > + +Sounds like your problem only occurs on older versions of Ubuntu, so moving this to the QEMU-Ubuntu bug tracker. + +Hi, +I mostly run with cloud-images so I haven't seen this yet (I always prefer uvtool-libvirt to virt-install). + +Thank you already for your good summary! + + +After going the wrong direction for a while I see the almost hidden, yet so important words - "in nested only" ! +That also explains the kvm-pr I wondered about, as I'd have expected kvm-hv if in 1st level. + + +I tried as you instructed - on first stage it worked (Host to lvl 1) + +Command: +$virt-install --virt-type=kvm --cpu=host --name=nested-xenial --controller type=scsi,model=virtio-scsi --graphics none --console pty,target_type=serial --disk path=/home/ubuntu/cpaelzer/test-xenial-virt-inst.qcow2,size=20 --vcpus=4 --ram=4096 --os-type=linux --os-variant ubuntu16.04 --network bridge=virbr0,model=virtio --cdrom=ubuntu-16.04-server-ppc64el.iso + +On a Xenial system with: +ii libvirt-bin 1.3.1-1ubuntu10.6 +ii qemu-kvm 1:2.5+dfsg-5ubuntu10.6 +ii virtinst 1:1.3.2-3ubuntu1.16.04.3 + +And HW: +POWER8E - PowerNV 8247-22L + + + +Now the same in 2nd level: +1. install all packages for kvm +2. ensure kvm_pr is loaded correctly +3. make sure libvirt default network can start in 2nd level +3. wget http://cdimage.ubuntu.com/releases/xenial/release/ubuntu-16.04-server-ppc64el.iso +4. virt-install as above, yet shrinked down to fit (5G disk) + +With that I can confirm your issue. + +I'm not entirely sure if kvm_pr (or more defined "the TM feature inside kvm_pr") is meant to be fully supported by IBM owning power in general. + +Subscribing / pinging them for their expertise on this. + +kvm_pr is not "officially/fully/formally" supported for production use, but this mode is extensively used by OpenStack Continuous Integration and it is the testing ground for many other projects. This statement of "not supported" has been changing and Power ecosystem depends on kvm_pr for platform enablement efforts. + + +The fix you referred to also is not upstream yet - although it is unclear to me why. +The discussion somehow just stalled +https://patchwork.kernel.org/patch/8740001/ + +As mentioned I was reaching out to IBM and they likely take a look at that patch once more now. + +Yep, for some reason, the discussion stalled. +Thanks for working on this bug. HTM bits should be cleared on nested virt, anyway. +Also, HTM is causing other components to fail on nested virt like rtas_errd daemon, which does PCI Hotplug. + +FYI, the pa_features[24] setting has been fixed in upstream in a slightly different way: +http://git.qemu-project.org/?p=qemu.git;a=commitdiff;h=bac3bf287ab60e264b6 + +Christian, + +I checked with Breno and while nested virtualization is not something that they encourage use of in a production environment, it is used for testing purposes. They would like to have this working with Ubuntu and have stated it only requires a small fix to qemu. If possible, could you please look at pulling in the fix. + +Thanks. + + Michael + +Thanks Thomas for pointing out the upstream fix. +IBM has opened a bug that I dup this one on. + +There not only one but three patches are suggested. +It would be great if you could take a look there as the patches are all yours - see the dup bug 1664622 + diff --git a/results/classifier/118/graphic/1665789 b/results/classifier/118/graphic/1665789 new file mode 100644 index 000000000..1cd04fd60 --- /dev/null +++ b/results/classifier/118/graphic/1665789 @@ -0,0 +1,45 @@ +graphic: 0.967 +device: 0.806 +socket: 0.764 +network: 0.729 +vnc: 0.721 +register: 0.675 +risc-v: 0.652 +mistranslation: 0.618 +boot: 0.615 +ppc: 0.598 +virtual: 0.588 +user-level: 0.579 +performance: 0.570 +i386: 0.568 +kernel: 0.553 +files: 0.547 +KVM: 0.545 +semantic: 0.537 +PID: 0.522 +arm: 0.520 +architecture: 0.515 +x86: 0.509 +VMM: 0.484 +TCG: 0.445 +permissions: 0.360 +debug: 0.342 +assembly: 0.328 +hypervisor: 0.242 +peripherals: 0.135 + +More resolutions for vga displays + +Would it be possible to add more resolutions for vga displays (which I am accessing via vnc instead of spice)? In particular: + +- 1080 wide x 1920 high (rotate 1920 x 1080 screen) + +- 1920 wide x 1080 + 1980 high (1920 x 1080 screen on top of 1600 x 900 screen) + +I noticed that we have multiple tickets for more resolutions opened. Let's consolidate all in https://bugs.launchpad.net/qemu/+bug/1022023 and close this one here as duplicate. + + +This is an automated cleanup. This bug report got closed because it +is a duplicate. + + diff --git a/results/classifier/118/graphic/1665791 b/results/classifier/118/graphic/1665791 new file mode 100644 index 000000000..36081c730 --- /dev/null +++ b/results/classifier/118/graphic/1665791 @@ -0,0 +1,36 @@ +mistranslation: 0.972 +graphic: 0.964 +semantic: 0.854 +device: 0.767 +vnc: 0.714 +architecture: 0.654 +network: 0.602 +arm: 0.587 +virtual: 0.583 +performance: 0.534 +register: 0.521 +risc-v: 0.507 +user-level: 0.307 +VMM: 0.288 +permissions: 0.269 +boot: 0.265 +assembly: 0.249 +peripherals: 0.216 +socket: 0.216 +ppc: 0.188 +debug: 0.171 +PID: 0.146 +i386: 0.124 +hypervisor: 0.121 +TCG: 0.089 +files: 0.066 +kernel: 0.060 +KVM: 0.044 +x86: 0.042 + +Multiple displays each attached to a separate vnc connection + +Would it be possible to create two displays in qemu (for windows 10) with each accessible by a separate vnc connection? I think this already exists for spice (and I would like it because vnc works better for me than does spice) + +Questions like this are better directed to the mailing list. Please email <email address hidden> and/or <email address hidden>. Thanks! + diff --git a/results/classifier/118/graphic/1671677 b/results/classifier/118/graphic/1671677 new file mode 100644 index 000000000..73c7f9e41 --- /dev/null +++ b/results/classifier/118/graphic/1671677 @@ -0,0 +1,62 @@ +graphic: 0.894 +peripherals: 0.858 +performance: 0.852 +boot: 0.842 +user-level: 0.835 +semantic: 0.800 +device: 0.798 +mistranslation: 0.784 +hypervisor: 0.777 +permissions: 0.748 +ppc: 0.744 +architecture: 0.737 +register: 0.668 +debug: 0.655 +network: 0.650 +PID: 0.640 +x86: 0.620 +files: 0.609 +KVM: 0.596 +i386: 0.580 +risc-v: 0.577 +kernel: 0.560 +socket: 0.556 +VMM: 0.526 +arm: 0.522 +TCG: 0.518 +virtual: 0.515 +assembly: 0.466 +vnc: 0.440 + +vfio-pci passthrough issue after resume from suspend + + +I'm running into a weird issue with the vfio-pci driver through qemu + +I use it on a laptop and I passthrough an external GPU connected via PCI express. In general this works well, however if the laptop has *ever* suspended since its last boot, then the windows guest reports an error 43 on the card and I get no output on the monitor that it is connected to. This is really weird to me since it works fine if I boot the latop from power-off, and hotplug the card. It's only if the laptop has ever suspended since it's last boot that I see this issue. Even if it was suspended before the card was ever hotplugged. + +In other words: +laptop off -> boot -> hotplug GPU : works great +laptop off -> boot -> do stuff (GPU *NOT* connected) -> sleep -> resume -> hotplug GPU: problem +laptop off -> boot -> hotplug GPU -> unplug GPU -> hotplug GPU : works great +laptop off -> boot -> hotplug GPU -> unplug GPU -> sleep -> resume -> hotplug GPU: problem + +Weird stuff... + +I'm honestly not sure that vfio-pci/qemu is to blame here since there are so many moving parts, but im not really sure where else to report this to + +What I have tried is using the sysfs interface to remove/rescan/poweroff/etc the PCI devices in questions (graphics card and it's HDMI audio) and this also does help. + +QEMU version: 2.6.1 + +Please let me know what other information I can provide + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to +"Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + + +I don't use this setup anymore so I don't know if it's still an issue, it would have been nice if someone had responded to my report when I filed it over 3 years ago. Go ahead and close it. + +Thanks for your answer, and sorry that nobody replied to your original report - sometimes there is just no expert around, or nobody has a clue about the right answer... anyway, let's close this ticket now. + diff --git a/results/classifier/118/graphic/1674 b/results/classifier/118/graphic/1674 new file mode 100644 index 000000000..50264fae8 --- /dev/null +++ b/results/classifier/118/graphic/1674 @@ -0,0 +1,53 @@ +graphic: 0.806 +architecture: 0.621 +semantic: 0.601 +peripherals: 0.598 +arm: 0.591 +permissions: 0.583 +device: 0.573 +PID: 0.556 +performance: 0.542 +socket: 0.539 +ppc: 0.518 +x86: 0.499 +virtual: 0.475 +kernel: 0.458 +network: 0.453 +vnc: 0.453 +VMM: 0.449 +files: 0.433 +hypervisor: 0.420 +TCG: 0.418 +debug: 0.417 +user-level: 0.396 +boot: 0.388 +i386: 0.364 +risc-v: 0.359 +register: 0.357 +mistranslation: 0.354 +KVM: 0.295 +assembly: 0.164 + +Arrow key not functional in QEMU monitor when using nographic on Windows 11 host +Description of problem: +The arrow keys do not work on the Windows QEMU when using -nographic option. On the Linux QEMU they work. +Steps to reproduce: +1. Download the qemu source code from https://download.qemu.org/qemu-8.0.0.tar.xz. THe sha256sum of the file is bb60f0341531181d6cc3969dd19a013d0427a87f918193970d9adb91131e56d0. +2. Prepare the build system on MSYS2 according to the instructions on https://wiki.qemu.org/Hosts/W32#Native_builds_with_MSYS2. +3. Uncompress the source code using `tar -xf qemu-8.0.0.tar.xz`. +4. Change the working directory to qemu-8.0.0/. The build configuration command is `./configure --target-list=arm-softmmu --extra-cflags="-g -ggdb"` +5. Run the command `./qemu-system-arm -s -S -M virt -nographic`. +6. Press Ctrl-C A to switch to QEMU monitor. +7. Input "help" command to the monitor. +8. Press Arrow-Up key. +9. The previous "help" command does not appear in the monitor prompt. +Additional information: +1. The pre-built binary downloaded from https://qemu.weilnetz.de/w64/qemu-w64-setup-20230424.exe has the same behaviour. +2. The QEMU from MSYS2, `pacman -S mingw-w64-x86_64-qemu`, has the same behaviour. +3. If the "-nographic" option is removed, the arrow-up key works in the GTK console. +4. Neither of arrow-up, arrow-down, arrow-right, arrow-left key work. +5. If the valid kernel and rootfs are added in the command line by "-kernel" and "-initrd" options, neither key work after booting to the Linux successfully. +6. If the code `dwMode |= ENABLE_LINE_INPUT;` in the function `qemu_chr_open_stdio()` is changed to `dwMode |= ENABLE_LINE_INPUT|ENABLE_VIRTUAL_TERMINAL_INPUT;`, build again. All arrow keys work. +7. The VT sequence support was added in `EmulatorPkg/Win/Host/WinThunk.c` by this commit https://gitlab.com/qemu-project/edk2/-/commit/5601e90d5cdbc4cea748e00e34ae07ce39bd700f. +8. The above commit is to add VT sequence support at compile-time. Microsoft provides some code to enable it at run-time on https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences#example-of-enabling-virtual-terminal-processing. +9. The function readline_handle_byte() is not called when the VT sequence is not enabled. diff --git a/results/classifier/118/graphic/1674056 b/results/classifier/118/graphic/1674056 new file mode 100644 index 000000000..9a53cdf9a --- /dev/null +++ b/results/classifier/118/graphic/1674056 @@ -0,0 +1,72 @@ +graphic: 0.907 +x86: 0.899 +peripherals: 0.895 +KVM: 0.884 +device: 0.849 +virtual: 0.828 +vnc: 0.826 +user-level: 0.805 +files: 0.727 +socket: 0.711 +semantic: 0.704 +kernel: 0.700 +architecture: 0.689 +ppc: 0.684 +mistranslation: 0.656 +performance: 0.646 +network: 0.629 +arm: 0.628 +debug: 0.564 +PID: 0.539 +permissions: 0.537 +hypervisor: 0.529 +register: 0.512 +TCG: 0.445 +i386: 0.420 +VMM: 0.419 +boot: 0.405 +risc-v: 0.399 +assembly: 0.349 + +USB keyboard and mouse sucked into qemu-kvm (somewhere) + +i am unable to run a command line qemu that does not "suck in" the keyboard and mouse of the host PC +i tried all that i could from the command line parameters i want to run a headless gui-less kvm host + +if i specify a second set of keyboard and mouse with the -usb the only thing that is diffrent is that i have a keyboard and mouse in the VM if i specify the host keyboard and mouse same thing ... the vm is working fine but the host has no control , no keyboard. i dont see any output of anything +the only recourse i have is ctrl+alt+delete and that resets the host after 2-3 times. + +i tried ctrl+alt, ctrl+alt+x , c , z , 2 , etc... also alt + all those combination and alt with F keys +no luck. + + +my command line looks like this (altough i tried many other variations) + +qemu-system-x86_64 -M q35 -enable-kvm \ +-cpu host,kvm=off -m 4096 -smp cpu=4,sockets=1,cores=4,treads=1 \ +-drive file=xyz.qcow2,if=scsi \ +-device vfio-pci, ... (GPU) \ +-device vfio-pci, .... (GPU audio) \ +-usb -usbdevice host:XXXX:XXXX -usbdevice host:XXXX:XXXX \ <<< same behaviour with and without +-vga none -vnc localhost:1 -daemonize + +i tried with -nographics , -curses, -monitor stdio, pty and none, same result and with -serial as well +tried </dev/null at the end of the command no luck same with & + +my guess is that the keyboard and mouse gets grabbed by the "window" of the qemu regardless if there is graphics or not and i have not foud a "-headless" ,"-nograb" or "-nopussygrab" mode . (yeah had to make the joke :P) + +hardware: +Z97N-wifi +Intel(R) Core(TM) i5-4690K CPU @ 3.50GHz +ram > 8Gb +keyboard is logitech +mouse is logitech + +distro is suse leap 42.1 (made with suseStudio) + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1676 b/results/classifier/118/graphic/1676 new file mode 100644 index 000000000..826de77cb --- /dev/null +++ b/results/classifier/118/graphic/1676 @@ -0,0 +1,37 @@ +architecture: 0.973 +mistranslation: 0.958 +graphic: 0.951 +device: 0.918 +network: 0.828 +arm: 0.810 +semantic: 0.803 +socket: 0.698 +VMM: 0.684 +files: 0.681 +performance: 0.658 +risc-v: 0.648 +user-level: 0.611 +PID: 0.606 +vnc: 0.600 +boot: 0.583 +permissions: 0.583 +ppc: 0.542 +debug: 0.524 +register: 0.512 +TCG: 0.501 +kernel: 0.383 +hypervisor: 0.350 +peripherals: 0.322 +i386: 0.306 +x86: 0.288 +KVM: 0.238 +assembly: 0.195 +virtual: 0.163 + +Signed release tarball for 8.0.2 is missing +Description of problem: +Hi! I package QEMU for Arch Linux. I usually rely on the signed tarballs (which are also linked to from the website). +For [8.0.2](https://gitlab.com/qemu-project/qemu/-/tags/v8.0.2) there does not seem to be a signed tarball though. +Steps to reproduce: +1. Try to update to 8.0.2 using a signed tarball +2. Find no signed tarball in https://download.qemu.org/ diff --git a/results/classifier/118/graphic/1678 b/results/classifier/118/graphic/1678 new file mode 100644 index 000000000..29ecabfd9 --- /dev/null +++ b/results/classifier/118/graphic/1678 @@ -0,0 +1,38 @@ +graphic: 0.984 +device: 0.876 +arm: 0.840 +architecture: 0.755 +x86: 0.750 +PID: 0.738 +files: 0.702 +register: 0.678 +permissions: 0.670 +semantic: 0.666 +VMM: 0.621 +vnc: 0.607 +network: 0.579 +mistranslation: 0.573 +socket: 0.561 +ppc: 0.557 +boot: 0.539 +performance: 0.539 +risc-v: 0.491 +TCG: 0.487 +kernel: 0.450 +debug: 0.424 +virtual: 0.350 +hypervisor: 0.307 +user-level: 0.280 +i386: 0.230 +peripherals: 0.184 +assembly: 0.098 +KVM: 0.095 + +Running Qemu on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work. +Description of problem: +Running QemuV8.0 on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work. +Steps to reproduce: +1.qemu-img.exe create hdd.img 10G +2.qemu-system-x86_64.exe -m 8096 hdd.img -cdrom ubuntu22.04-desktop-amd64.iso -machine pc +Additional information: +both Use qemu v8.0 and qemu v8.1 to test, but failed also diff --git a/results/classifier/118/graphic/1679 b/results/classifier/118/graphic/1679 new file mode 100644 index 000000000..31d25d263 --- /dev/null +++ b/results/classifier/118/graphic/1679 @@ -0,0 +1,45 @@ +graphic: 0.978 +arm: 0.814 +device: 0.805 +x86: 0.775 +semantic: 0.644 +architecture: 0.638 +mistranslation: 0.530 +PID: 0.498 +permissions: 0.458 +debug: 0.430 +files: 0.418 +performance: 0.408 +vnc: 0.386 +boot: 0.385 +register: 0.384 +ppc: 0.378 +network: 0.300 +socket: 0.284 +VMM: 0.268 +virtual: 0.250 +hypervisor: 0.249 +TCG: 0.244 +user-level: 0.229 +risc-v: 0.173 +kernel: 0.132 +i386: 0.122 +peripherals: 0.094 +assembly: 0.038 +KVM: 0.031 + +Running Qemu on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work.Enter the issue title +Description of problem: +Running QemuV8.0 on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work. +Steps to reproduce: +1.qemu-img.exe create hdd.img 10G + +2.qemu-system-x86_64.exe -m 8096 hdd.img -cdrom ubuntu22.04-desktop-amd64.iso -machine pc +Additional information: +both Use qemu v8.0 and qemu v8.1 to test, but failed also + + + +Thanks, + +Jianbin diff --git a/results/classifier/118/graphic/1681 b/results/classifier/118/graphic/1681 new file mode 100644 index 000000000..a51546999 --- /dev/null +++ b/results/classifier/118/graphic/1681 @@ -0,0 +1,79 @@ +graphic: 0.936 +register: 0.934 +permissions: 0.930 +TCG: 0.909 +mistranslation: 0.909 +debug: 0.908 +peripherals: 0.889 +device: 0.889 +KVM: 0.887 +risc-v: 0.886 +vnc: 0.883 +performance: 0.876 +PID: 0.868 +assembly: 0.867 +user-level: 0.861 +virtual: 0.855 +semantic: 0.852 +ppc: 0.851 +arm: 0.836 +hypervisor: 0.825 +network: 0.812 +i386: 0.802 +files: 0.800 +VMM: 0.797 +socket: 0.796 +architecture: 0.791 +boot: 0.773 +kernel: 0.772 +x86: 0.681 + +watchdog: BUG: soft lockup - CPU#N stuck for XXs! +Description of problem: +Repeatedly seeing Qemu VMs locking up with guest Linux kernel reporting: +"watchdog: BUG: soft lockup - CPU#<N> stuck for <XX>s!" +e.g.: "watchdog: BUG: soft lockup - CPU#5 stuck for 26s! [swapper/5:0]" + +When the guest VM is in this condition, the host Linux OS reports that the Qemu process is typically running steadily at ~250% CPU. +Steps to reproduce: +1. Windows 10 on an x64 PC (right on the metal). +2. VMWare Workstation running Fedora Workstation 38 x64 guest, in turn acting as host with nested virtualization. +3. Qemu 7.2.1 running on Fedora host with Fedora Server 38 x64 guest. +4. Invoke Qemu using F38 QCow2 image: `$ qemu-system-x86_64 -machine pc -cpu max -smp 8 -accel kvm -accel hvf -accel tcg -m 3G -nographic -hda Client.qcow2 -nic socket,model=virtio-net-pci,mcast=239.1.2.3:4567,mac=4a:e0:72:85:c0:fb -nic user,model=virtio-net-pci,mac=4a:e0:d8:cd:a5:e6,hostfwd=tcp:127.0.0.1:2288-:22` +5. Not necessarily right away, but pretty consistently if left running overnight, guest Linux kernel repeatedly reports CPU(s) stuck, guest VM is unresponsive +6. Host Linux `top` reports Qemu process using ~250% CPU. +Additional information: +Console log attached, small sample here: + +``` +[ 181.101152] watchdog: BUG: soft lockup - CPU#5 stuck for 26s! [swapper/5:0] +[ 181.145578] Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nfg +[ 181.145578] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 6.2.9-300.fc38.x86_64 #1 +[ 181.145578] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014 +[ 181.145578] RIP: 0010:netif_receive_skb_list_internal+0x58/0x300 +[ 181.145578] Code: 4c 89 74 24 08 49 89 ec 4c 89 74 24 10 4c 8b 6d 00 48 39 ef 75 14 eb 7c 49 8b 8 +[ 181.145578] RSP: 0018:ff5a086d401b8da8 EFLAGS: 00000202 +[ 181.145578] RAX: 0000000000000000 RBX: ff2d02b1b404c910 RCX: 0000000000000100 +[ 181.145578] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ff2d02b1b404c910 +[ 181.145578] RBP: ff2d02b18998a600 R08: 0000000000000001 R09: ff2d02b188bd5d00 +[ 181.145578] R10: 000000000000000c R11: ffa7ad3980175000 R12: ff2d02b18998a600 +[ 181.145578] R13: ff2d02b1b404c910 R14: ff5a086d401b8db0 R15: ff2d02b1882d19c0 +[ 181.145578] FS: 0000000000000000(0000) GS:ff2d02b23cb40000(0000) knlGS:0000000000000000 +[ 181.145578] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 181.145578] CR2: 00007f232000f0d8 CR3: 0000000027010000 CR4: 0000000000751ee0 +[ 181.145578] PKRU: 55555554 +[ 181.145578] Call Trace: +[ 181.145578] <IRQ> +[ 181.145578] napi_complete_done+0x6e/0x1a0 +[ 181.145578] virtnet_poll+0x420/0x550 [virtio_net] +[ 181.145578] __napi_poll+0x2b/0x1b0 +[ 181.145578] net_rx_action+0x2a5/0x360 +[ 181.145578] ? vp_vring_interrupt+0x73/0x90 +[ 181.145578] __do_softirq+0xfd/0x31a +[ 181.145578] __irq_exit_rcu+0xd7/0x140 +[ 181.145578] common_interrupt+0xb9/0xd0 +[ 181.145578] </IRQ> +[ 181.145578] <TASK> +[ 181.145578] asm_common_interrupt+0x22/0x40 +[ 181.145578] RIP: 0010:native_safe_halt+0xb/0x10 +``` diff --git a/results/classifier/118/graphic/1687214 b/results/classifier/118/graphic/1687214 new file mode 100644 index 000000000..5cdcb0c43 --- /dev/null +++ b/results/classifier/118/graphic/1687214 @@ -0,0 +1,51 @@ +graphic: 0.894 +device: 0.824 +performance: 0.719 +user-level: 0.708 +network: 0.673 +semantic: 0.542 +permissions: 0.518 +socket: 0.502 +mistranslation: 0.489 +register: 0.456 +PID: 0.431 +arm: 0.428 +peripherals: 0.421 +debug: 0.419 +hypervisor: 0.409 +boot: 0.386 +architecture: 0.376 +vnc: 0.354 +ppc: 0.354 +risc-v: 0.344 +files: 0.336 +virtual: 0.304 +VMM: 0.291 +kernel: 0.234 +i386: 0.220 +x86: 0.215 +assembly: 0.177 +TCG: 0.117 +KVM: 0.065 + +Rapid tremendous memory hog when using -net nic,vlan=0 -net user,vlan=0 + +A rapid tremendous memory hog is occuring when I use -net nic,vlan=0 -net user,vlan=0. Tested with QEMU 2.8.0 & 2.9.0 in Gentoo. All available memory (8GB) + swap (over 20GB) is exhausted very rapidly. + +This bug is possibly related to +https://bugs.launchpad.net/qemu/+bug/1310714 +and maybe to +https://bugs.launchpad.net/qemu/+bug/1288620 + +The bug IS present wheh I use -net nic,vlan=0 -net user,vlan=0 (tested with no model and model=e1000 and model=virtio, with all these the bug is present) + +The bug is NOT present with I use this: +-netdev type=user,id=mynet0 -device virtio-net-pci,netdev=mynet0 + +I tested this bug only using windows guests (Windows XP & Windows 8). + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1687569 b/results/classifier/118/graphic/1687569 new file mode 100644 index 000000000..fb2df583f --- /dev/null +++ b/results/classifier/118/graphic/1687569 @@ -0,0 +1,93 @@ +graphic: 0.811 +permissions: 0.809 +performance: 0.789 +user-level: 0.754 +mistranslation: 0.750 +architecture: 0.748 +virtual: 0.742 +semantic: 0.719 +files: 0.698 +register: 0.683 +device: 0.680 +assembly: 0.663 +arm: 0.644 +PID: 0.640 +KVM: 0.629 +TCG: 0.629 +vnc: 0.619 +peripherals: 0.600 +debug: 0.597 +hypervisor: 0.594 +risc-v: 0.587 +x86: 0.573 +VMM: 0.570 +network: 0.565 +socket: 0.562 +ppc: 0.558 +kernel: 0.511 +boot: 0.484 +i386: 0.479 + +when migration cancel, qemu main thread hung + +qemu version:v2.9.0-rc5 release + +1.virsh migrate --live 165cf436-312f-47e7-90f2-f8aa63f34893 --copy-storage-all qemu+ssh://10.59.163.38/system +2.press Ctrl+C cancel migrate + + qemu main thread hung + +(gdb) bt +#0 0x00007fca9f4574b7 in ppoll () from /lib64/libc.so.6 +#1 0x0000000000944970 in qemu_poll_ns (fds=0x293e6e0, nfds=1, timeout=-1) at util/qemu-timer.c:322 +#2 0x0000000000947e16 in aio_poll (ctx=0x291d4b0, blocking=true) at util/aio-posix.c:622 +#3 0x00000000008b6094 in nbd_teardown_connection (bs=0x29ccdc0) at block/nbd-client.c:59 +#4 0x00000000008b6df1 in nbd_client_close (bs=0x29ccdc0) at block/nbd-client.c:377 +#5 0x00000000008b5988 in nbd_close (bs=0x29ccdc0) at block/nbd.c:488 +#6 0x00000000008435de in bdrv_close (bs=0x29ccdc0) at block.c:2919 +#7 0x0000000000843c86 in bdrv_delete (bs=0x29ccdc0) at block.c:3100 +#8 0x000000000084620b in bdrv_unref (bs=0x29ccdc0) at block.c:4087 +#9 0x00000000008411d1 in bdrv_root_unref_child (child=0x30e4800) at block.c:1891 +#10 0x000000000084128a in bdrv_unref_child (parent=0x29c0660, child=0x30e4800) at block.c:1915 +#11 0x000000000084362a in bdrv_close (bs=0x29c0660) at block.c:2925 +#12 0x0000000000843c86 in bdrv_delete (bs=0x29c0660) at block.c:3100 +#13 0x000000000084620b in bdrv_unref (bs=0x29c0660) at block.c:4087 +#14 0x00000000008411d1 in bdrv_root_unref_child (child=0x3013910) at block.c:1891 +#15 0x0000000000848149 in block_job_remove_all_bdrv (job=0x3fa7800) at blockjob.c:154 +#16 0x00000000008a8dd8 in mirror_exit (job=0x3fa7800, opaque=0x7fca90000bf0) at block/mirror.c:576 +#17 0x0000000000849e22 in block_job_defer_to_main_loop_bh (opaque=0x7fca90000d90) at blockjob.c:794 +#18 0x00000000009420c4 in aio_bh_call (bh=0x7fca90000dc0) at util/async.c:90 +#19 0x000000000094216f in aio_bh_poll (ctx=0x291d4b0) at util/async.c:118 +#20 0x00000000009480d9 in aio_poll (ctx=0x291d4b0, blocking=true) at util/aio-posix.c:682 +#21 0x00000000008b6094 in nbd_teardown_connection (bs=0x2921350) at block/nbd-client.c:59 +#22 0x00000000008b6df1 in nbd_client_close (bs=0x2921350) at block/nbd-client.c:377 +#23 0x00000000008b5988 in nbd_close (bs=0x2921350) at block/nbd.c:488 +#24 0x00000000008435de in bdrv_close (bs=0x2921350) at block.c:2919 +#25 0x0000000000843c86 in bdrv_delete (bs=0x2921350) at block.c:3100 +#26 0x000000000084620b in bdrv_unref (bs=0x2921350) at block.c:4087 +#27 0x00000000008411d1 in bdrv_root_unref_child (child=0x390d180) at block.c:1891 +#28 0x000000000084128a in bdrv_unref_child (parent=0x4eba200, child=0x390d180) at block.c:1915 +#29 0x000000000084362a in bdrv_close (bs=0x4eba200) at block.c:2925 +#30 0x0000000000843c86 in bdrv_delete (bs=0x4eba200) at block.c:3100 +#31 0x000000000084620b in bdrv_unref (bs=0x4eba200) at block.c:4087 +#32 0x00000000008411d1 in bdrv_root_unref_child (child=0x4ebf990) at block.c:1891 +#33 0x0000000000848149 in block_job_remove_all_bdrv (job=0x4ea85b0) at blockjob.c:154 +#34 0x00000000008a8dd8 in mirror_exit (job=0x4ea85b0, opaque=0x7fca98000bf0) at block/mirror.c:576 +#35 0x0000000000849e22 in block_job_defer_to_main_loop_bh (opaque=0x7fca980013d0) at blockjob.c:794 +#36 0x00000000009420c4 in aio_bh_call (bh=0x7fca9801e0c0) at util/async.c:90 +#37 0x000000000094216f in aio_bh_poll (ctx=0x291d4b0) at util/async.c:118 +---Type <return> to continue, or q <return> to quit--- +#38 0x00000000009476ae in aio_dispatch (ctx=0x291d4b0) at util/aio-posix.c:429 +#39 0x00000000009425e4 in aio_ctx_dispatch (source=0x291d4b0, callback=0, user_data=0x0) at util/async.c:261 +#40 0x00007fcaa0101f0e in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 +#41 0x0000000000945d86 in glib_pollfds_poll () at util/main-loop.c:213 +#42 0x0000000000945ea7 in os_host_main_loop_wait (timeout=124777230) at util/main-loop.c:261 +#43 0x0000000000945f72 in main_loop_wait (nonblocking=0) at util/main-loop.c:517 +#44 0x00000000005c7794 in main_loop () at vl.c:1898 +#45 0x00000000005cec57 in main (argc=64, argv=0x7fffe7020c58, envp=0x7fffe7020e60) at vl.c:4709 + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1687599 b/results/classifier/118/graphic/1687599 new file mode 100644 index 000000000..76b33ba26 --- /dev/null +++ b/results/classifier/118/graphic/1687599 @@ -0,0 +1,59 @@ +graphic: 0.852 +PID: 0.851 +x86: 0.823 +virtual: 0.792 +device: 0.791 +performance: 0.786 +network: 0.786 +permissions: 0.785 +user-level: 0.769 +semantic: 0.764 +peripherals: 0.744 +socket: 0.733 +architecture: 0.729 +ppc: 0.708 +hypervisor: 0.674 +i386: 0.604 +kernel: 0.600 +VMM: 0.590 +files: 0.553 +debug: 0.526 +mistranslation: 0.519 +assembly: 0.493 +register: 0.479 +vnc: 0.455 +arm: 0.446 +boot: 0.433 +KVM: 0.430 +risc-v: 0.368 +TCG: 0.264 + +Bind 2nd VM to same OVS vhost-user port caused 1st vm traffic broken + +Binding 2nd VM to same OVS vhost-user port caused 1st vm traffic broken. If it illegal to share same vhost port, how about the first VM open the path exclusively? + + +#OVS side to create the vhost-user port: +ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev +ovs-vsctl add-port br0 phy0 -- set Interface phy0 type=dpdk options:dpdk-devargs=0000:0a:00.0 +ovs-vsctl add-port br0 dpdkvhostuser0 -- set Interface dpdkvhostuser0 type=dpdkvhostuser + +#QEMU VM1 +qemu-system-x86_64 -name vm1 -cpu host -enable-kvm -m 3072 -drive file=/opt/ubuntu1.qcow2 \ + -numa node,memdev=mem -mem-prealloc -smp sockets=1,cores=2 \ + -object memory-backend-file,id=mem,size=3072m,mem-path=/dev/hugepages,share=on \ + -chardev socket,id=char0,path=/usr/local/var/run/openvswitch/dpdkvhostuser0 \ -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \ + -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mrg_rxbuf=off + +#VM2 +qemu-system-x86_64 -name vm2 -cpu host -enable-kvm -m 3072 -drive file=/opt/ubuntu2.qcow2 \ + -numa node,memdev=mem -mem-prealloc -smp sockets=1,cores=2 \ + -object memory-backend-file,id=mem,size=3072m,mem-path=/dev/hugepages,share=on \ + -chardev socket,id=char0,path=/usr/local/var/run/openvswitch/dpdkvhostuser0 \ -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \ + -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mrg_rxbuf=off + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1687653 b/results/classifier/118/graphic/1687653 new file mode 100644 index 000000000..bb4dd0c65 --- /dev/null +++ b/results/classifier/118/graphic/1687653 @@ -0,0 +1,168 @@ +graphic: 0.909 +semantic: 0.876 +mistranslation: 0.857 +user-level: 0.845 +arm: 0.835 +hypervisor: 0.827 +TCG: 0.823 +assembly: 0.810 +performance: 0.796 +register: 0.792 +device: 0.790 +peripherals: 0.784 +permissions: 0.778 +virtual: 0.774 +architecture: 0.767 +debug: 0.761 +PID: 0.756 +kernel: 0.755 +KVM: 0.753 +ppc: 0.750 +VMM: 0.738 +boot: 0.720 +vnc: 0.689 +files: 0.667 +socket: 0.662 +network: 0.655 +risc-v: 0.610 +x86: 0.582 +i386: 0.474 + +QEMU-KVM / detect_zeroes causes KVM to start unlimited number of threads on Guest-Sided High-IO with big Blocksize + +QEMU-KVM in combination with "detect_zeroes=on" makes a Guest able to DoS the Host. This is possible if the Host itself has "detect_zeroes" enabled and the Guest writes a large Chunk of data with a huge blocksize onto the drive. + +E.g.: dd if=/dev/zero of=/tmp/DoS bs=1G count=1 oflag=direct + +All QEMU-Versions after implementation of detect_zeroes are affected. Prior are unaffected. This is absolutely critical, please fix this ASAP! + +##### + +Provided by Dominik Csapak: + +source , bs , count , O_DIRECT, behaviour + +urandom , bs 1M, count 1024, O_DIRECT: OK +file , bs 1M, count 1024, O_DIRECT: OK +/dev/zero , bs 1M, count 1024, O_DIRECT: OK +zero file , bs 1M, count 1024, O_DIRECT: OK +/dev/zero , bs 1G, count 1, O_DIRECT: NOT OK +zero file , bs 1G, count 1, O_DIRECT: NOT OK +zero file , bs 1G, count 1, no O_DIRECT: NOT OK +rand file , bs 1G, count 1, O_DIRECT: OK +rand file , bs 1G, count 1, no O_DIRECT: OK + +discard on: + +urandom , bs 1M, count 1024, O_DIRECT: OK +rand file , bs 1M, count 1024, O_DIRECT: OK +/dev/zero , bs 1M, count 1024, O_DIRECT: OK +zero file , bs 1M, count 1024, O_DIRECT: OK +/dev/zero , bs 1G, count 1, O_DIRECT: NOT OK +zero file , bs 1G, count 1, O_DIRECT: NOT OK +zero file , bs 1G, count 1, no O_DIRECT: NOT OK +rand file , bs 1G, count 1, O_DIRECT: OK +rand file , bs 1G, count 1, no O_DIRECT: OK + +detect_zeros off: + +urandom , bs 1M, count 1024, O_DIRECT: OK +rand file , bs 1M, count 1024, O_DIRECT: OK +/dev/zero , bs 1M, count 1024, O_DIRECT: OK +zero file , bs 1M, count 1024, O_DIRECT: OK +/dev/zero , bs 1G, count 1, O_DIRECT: OK +zero file , bs 1G, count 1, O_DIRECT: OK +zero file , bs 1G, count 1, no O_DIRECT: OK +rand file , bs 1G, count 1, O_DIRECT: OK +rand file , bs 1G, count 1, no O_DIRECT: OK + +##### + +Provided by Florian Strankowski + +bs - count - io-threads + +512K - 2048 - 2 +1M - 1024 - 2 +2M - 512 - 4 +4M - 256 - 6 +8M - 128 - 10 +16M - 64 - 18 +32M - 32 - uncountable + +Please refer to further information here: + +https://bugzilla.proxmox.com/show_bug.cgi?id=1368 + + + +Sorry ab out the visibility settings, this bugtracker drives me nuts. + +Just to make this clear: This bug affects only LVM-backed storages. File-based-storage is not affected. LVM-Thin and also LVM-Thick. + +Status changed to 'Confirmed' because the bug affects multiple users. + +I'm unable to reproduce this issue. The host stays responsive and the dd command completes in a reasonable amount of time. QEMU does not exceed the 64-thread pool size. + +Please post steps to reproduce the issue using a minimal command-line without libvirt. + +Here is information on my attempt to reproduce the problem: + +Guest: Kernel 4.10.8-200.fc25.x86_64 +Host: 4.10.11-200.fc25.x86_64 +QEMU: qemu.git/master (e619b14746e5d8c0e53061661fd0e1da01fd4d60) + +The LV is 1 GB on top of LUKS on a Samsung MZNLN256HCHP SATA SSD drive. + +mpstat -P ALL 5 output: +11:02:02 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle +11:02:07 AM all 3.36 0.00 6.22 34.54 0.25 0.50 0.00 3.11 0.00 52.03 +11:02:07 AM 0 2.82 0.00 5.63 32.39 0.80 1.21 0.00 3.22 0.00 53.92 +11:02:07 AM 1 3.02 0.00 6.04 28.77 0.20 0.20 0.00 3.02 0.00 58.75 +11:02:07 AM 2 3.56 0.00 7.71 44.27 0.20 0.40 0.00 2.37 0.00 41.50 +11:02:07 AM 3 3.81 0.00 5.61 32.46 0.00 0.40 0.00 4.01 0.00 53.71 + +vmstat 5 output: +procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- + r b swpd free buff cache si so bi bo in cs us sy id wa st + 0 0 0 1617404 6484 3541468 0 0 2145 84794 1976 8814 8 8 64 20 0 + 0 0 0 1619492 6484 3538592 0 0 613 69340 1518 7430 6 7 70 17 0 + 0 0 0 1618920 6484 3538680 0 0 280 75199 1421 6811 6 7 52 35 0 + +pidstat -v -p $PID_OF_QEMU 5 output: +11:01:08 AM UID PID threads fd-nr Command +11:02:03 AM 0 13043 67 37 qemu-system-x86 +11:02:08 AM 0 13043 67 37 qemu-system-x86 +11:02:13 AM 0 13043 67 37 qemu-system-x86 + +$ sudo x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 -cpu host \ + -device virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5 \ + -drive file=test.img,if=none,id=drive-scsi0,format=raw,cache=none,aio=native,detect-zeroes=on \ + -device scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100 \ + -drive file=/dev/path/to/testlv,if=none,id=drive-scsi1,format=raw,cache=none,aio=native,detect-zeroes=on \ + -device scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi1,id=scsi1,bootindex=101 \ + -nographic + +guest# dd if=/dev/zero of=/dev/sdb bs=1G count=1 oflag=direct +1+0 records in +1+0 records out +1073741824 bytes (1.1 GB, 1.0 GiB) copied, 15.0681 s, 71.3 MB/s + +Please be so kind and go for a 6G LVM-Vol and do "dd if=/dev/zero of=/dev/sdb bs=3G count=2 oflag=direct". Please keep an eye on your processor usage in comparison to the threads created. Its harder to knock-down an SSD-Backed system than one with spinners. + + + +After further investigation on IRC the following points were raised: + +1. Non-vcpu threads in QEMU weren't being isolated. Libvirt can do this + using the <cputune> domain XML element. The guest can create a high + load if some QEMU threads are unconstrained. + +2. The wait% CPU stat was causing confusion. It's the idle time during + which synchronous I/O is pending. High wait% does not mean that the + system is under high CPU load. detect-zeroes=on can take a + synchronous I/O path even when aio=native is used, and this results + in wait% instead of idle%. + +I'm closing the bug. + diff --git a/results/classifier/118/graphic/1689003 b/results/classifier/118/graphic/1689003 new file mode 100644 index 000000000..9f66697c4 --- /dev/null +++ b/results/classifier/118/graphic/1689003 @@ -0,0 +1,51 @@ +graphic: 0.836 +performance: 0.828 +semantic: 0.779 +device: 0.775 +architecture: 0.747 +peripherals: 0.733 +permissions: 0.728 +network: 0.715 +ppc: 0.714 +files: 0.706 +mistranslation: 0.683 +debug: 0.680 +PID: 0.676 +register: 0.668 +socket: 0.661 +user-level: 0.648 +kernel: 0.615 +vnc: 0.611 +risc-v: 0.570 +i386: 0.569 +hypervisor: 0.560 +x86: 0.547 +VMM: 0.546 +TCG: 0.512 +boot: 0.511 +assembly: 0.471 +virtual: 0.465 +arm: 0.431 +KVM: 0.424 + +USB passthrough should not fail if SET CONFIGURATION fails + +QEMU's USB passthrough was not working for my new smartphone. + +While analyzing the problem, I found out that a SET CONFIGURATION Request was NACKed by the USB device (probably because a SET CONFIGURATION request was already sent from the host to the device). + +So I wrote a simple program to fake a successful call to libusb_set_configuration and did an LD_PRELOAD on this program before starting qemu, and it worked. + +Looking at QEMU's code in host-libusb.c, I can see that QEMU does not try to claim the interface if its call to libusb_set_configuration fails. + +I think QEMU should try to claim the device anyway even if libusb_set_configuration fails. + +I did my tests against QEMU 2.6.2, but as I can see from the source code, this problem should happen on all versions. + +The attached simple program, compiled as a library, loaded by LD_PRELOAD before starting QEMU, avoids the problem by faking success of libusb_set_configuration(), as a workaround. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1689245 b/results/classifier/118/graphic/1689245 new file mode 100644 index 000000000..bcb00d6dd --- /dev/null +++ b/results/classifier/118/graphic/1689245 @@ -0,0 +1,52 @@ +graphic: 0.868 +device: 0.798 +hypervisor: 0.767 +semantic: 0.759 +performance: 0.745 +files: 0.729 +virtual: 0.706 +ppc: 0.678 +assembly: 0.668 +architecture: 0.578 +x86: 0.577 +i386: 0.553 +user-level: 0.550 +debug: 0.522 +PID: 0.507 +boot: 0.503 +network: 0.493 +socket: 0.442 +permissions: 0.438 +register: 0.434 +VMM: 0.386 +mistranslation: 0.386 +peripherals: 0.352 +vnc: 0.323 +risc-v: 0.317 +KVM: 0.294 +arm: 0.241 +kernel: 0.235 +TCG: 0.183 + +qcow2 image converted from Photon OS can't be started + +Steps to reproduce the issue: +1. Download the ovf from this place: +https://bintray.com/vmware/photon/download_file?file_path=photon-custom-hw10-1.0-62c543d.ova +2. Extract vmdk from ova file. +3. Convert from vmdk fromat to qcow2 via qeum-img +4. Launch the qcow2 image. The VM is started. But there is no any output. CPU usage is 100% + +I try this steps and meet the similar issue: +1. Deploy a VM in ESXi from https://bintray.com/vmware/photon/download_file?file_path=photon-custom-hw10-1.0-62c543d.ova +2. Copy vmdk and flat.vmdk file +3. Convert from vmdk format to raw via qeum-img(qemu-img convert -f vmdk -O raw Photon.vmdk Photon.raw) +4. Launch the qcow2 image. The VM is started. And the splash screen is showed. But then there is no any output. + +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. + +Additional question if this is still relevant: How did you run QEMU here, i.e. which command line parameters did you use? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1695 b/results/classifier/118/graphic/1695 new file mode 100644 index 000000000..d56f50e73 --- /dev/null +++ b/results/classifier/118/graphic/1695 @@ -0,0 +1,41 @@ +graphic: 0.986 +architecture: 0.848 +device: 0.834 +vnc: 0.784 +network: 0.780 +semantic: 0.738 +permissions: 0.704 +register: 0.702 +ppc: 0.684 +performance: 0.679 +hypervisor: 0.672 +files: 0.669 +debug: 0.659 +socket: 0.656 +VMM: 0.647 +arm: 0.585 +PID: 0.583 +kernel: 0.579 +risc-v: 0.574 +peripherals: 0.566 +TCG: 0.559 +KVM: 0.550 +boot: 0.404 +assembly: 0.394 +i386: 0.376 +x86: 0.328 +user-level: 0.328 +virtual: 0.318 +mistranslation: 0.297 + +Latest Windows MSI does not include libssp-0.dll +Description of problem: +The latest Qemu MSI installer for Windows (https://qemu.weilnetz.de/w64/2023/qemu-w64-setup-20230530.exe) does not include libssp-0.dll, which is why the executables fail to run. + +This Mingw library should be included when building the MSI if stack protection is enabled. +Steps to reproduce: +1. Install the latest qemu MSI +2. Try to invoke any qemu command +3. Use Dependency Walker to easily find missing dependencies (https://www.dependencywalker.com/) +Additional information: + diff --git a/results/classifier/118/graphic/1702 b/results/classifier/118/graphic/1702 new file mode 100644 index 000000000..044c0e349 --- /dev/null +++ b/results/classifier/118/graphic/1702 @@ -0,0 +1,38 @@ +graphic: 0.933 +boot: 0.852 +device: 0.776 +performance: 0.740 +semantic: 0.709 +kernel: 0.448 +files: 0.389 +debug: 0.320 +architecture: 0.303 +user-level: 0.256 +mistranslation: 0.255 +i386: 0.214 +TCG: 0.206 +peripherals: 0.175 +x86: 0.149 +network: 0.138 +assembly: 0.124 +PID: 0.108 +arm: 0.107 +VMM: 0.100 +vnc: 0.092 +KVM: 0.080 +risc-v: 0.070 +hypervisor: 0.069 +register: 0.066 +virtual: 0.064 +permissions: 0.044 +socket: 0.044 +ppc: 0.041 + +Enable whpx acceleration, unable to start Linux system +Description of problem: +The accel=whpx parameter stops responding in the boot menu. + +The accel=whpx,kernel-irqchip=off parameter stops responding during startup +Additional information: + + diff --git a/results/classifier/118/graphic/1707 b/results/classifier/118/graphic/1707 new file mode 100644 index 000000000..a07c7e431 --- /dev/null +++ b/results/classifier/118/graphic/1707 @@ -0,0 +1,53 @@ +graphic: 0.935 +architecture: 0.915 +user-level: 0.914 +x86: 0.831 +files: 0.772 +device: 0.750 +semantic: 0.707 +PID: 0.698 +network: 0.686 +socket: 0.612 +performance: 0.610 +mistranslation: 0.607 +permissions: 0.510 +vnc: 0.460 +register: 0.441 +TCG: 0.439 +ppc: 0.417 +debug: 0.413 +VMM: 0.396 +hypervisor: 0.340 +boot: 0.339 +risc-v: 0.326 +arm: 0.305 +KVM: 0.303 +peripherals: 0.291 +kernel: 0.288 +virtual: 0.242 +i386: 0.208 +assembly: 0.102 + +linux-user qemu-x86_64 can't exec a binary on aarch64 or Loongarch. +Description of problem: +on master branch, we build an simply hello.c with x86_cross gcc. +then. run './build/qemu-x86_64 hello', no output. +Steps to reproduce: +1. build an hello.c with x86_64 cross. use --static. +2. build qemu-x86_64 on aarch64 or LoongArch host. +3. run './build/qemu-x86_64 hello' +Additional information: +[strace.txt](/uploads/5362e0e9b04ad9a582470faf4a9fcedb/strace.txt) + + + + [hello](/uploads/12d9277fa4e853286414f575010a37ac/hello) + + +The following commit causes this problem． + +commit 86f04735ac2088d5c069c3d1712212ec7428c562 +Author: Helge Deller <deller@gmx.de> +Date: Sun Dec 25 09:23:19 2022 +0100 + + linux-user: Fix brk() to release pages diff --git a/results/classifier/118/graphic/1709 b/results/classifier/118/graphic/1709 new file mode 100644 index 000000000..1ba3d321f --- /dev/null +++ b/results/classifier/118/graphic/1709 @@ -0,0 +1,66 @@ +graphic: 0.837 +device: 0.758 +ppc: 0.745 +semantic: 0.729 +files: 0.691 +peripherals: 0.679 +PID: 0.679 +user-level: 0.660 +performance: 0.635 +permissions: 0.620 +socket: 0.616 +network: 0.590 +architecture: 0.584 +x86: 0.583 +risc-v: 0.567 +debug: 0.537 +vnc: 0.516 +hypervisor: 0.489 +kernel: 0.449 +mistranslation: 0.447 +VMM: 0.431 +register: 0.422 +i386: 0.409 +arm: 0.392 +boot: 0.379 +assembly: 0.374 +KVM: 0.367 +TCG: 0.358 +virtual: 0.230 + +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/118/graphic/1712564 b/results/classifier/118/graphic/1712564 new file mode 100644 index 000000000..486dc8100 --- /dev/null +++ b/results/classifier/118/graphic/1712564 @@ -0,0 +1,62 @@ +graphic: 0.831 +PID: 0.802 +ppc: 0.725 +device: 0.723 +kernel: 0.720 +socket: 0.684 +vnc: 0.682 +performance: 0.667 +architecture: 0.662 +permissions: 0.655 +assembly: 0.651 +VMM: 0.643 +hypervisor: 0.643 +network: 0.640 +arm: 0.636 +user-level: 0.626 +register: 0.620 +mistranslation: 0.592 +peripherals: 0.586 +debug: 0.579 +semantic: 0.553 +risc-v: 0.552 +x86: 0.526 +TCG: 0.521 +files: 0.514 +boot: 0.466 +virtual: 0.458 +KVM: 0.410 +i386: 0.399 + +loadvm fails twice in sequence + +13:38:23) shorne_: Hello, I was doing some testing with migrations for my OpenRISC SMP patch set, I noticed something that looks like a bug, wondering if someone else wants to confirm +(13:38:47) shorne_: Basically, calling loadvm 2 times causes crash +(13:38:54) shorne_: migration/savevm.c: qemu_event_set(&mis->main_thread_load_event) +(13:38:54) stefanha: fam: Here is my take at this change: https://paste.debian.net/982690/ +(13:38:56) shorne_: assert(ev->initialized) - fails inside +(13:39:32) stefanha: quintela davidgiluk: ^ +(13:41:23) ***davidgiluk looks +(13:41:40) shorne_: c096358e747 util/qemu-thread-posix.c (Fam Zheng 2017-07-04 20:23:25 +0800 397) assert(ev->initialized); +(13:41:51) davidgiluk: shorne_: So you're doing a loadvm to load a snapshot and then again? +(13:42:02) shorne_: Looks like adding that assert() was done really recently +(13:42:41) shorne_: yes, just loadvm 'a' ... then wait a bit longer, loadvm 'a' again (confirm clocks go back etc) +(13:42:50) stefanha: fam: While you're having dinner I'll work on turning my script into a qemu-iotests test case that we can merge. +(13:44:03) gpiccoli [~gpiccoli@0002093a.user.oftc.net] entered the room. +(13:44:21) davidgiluk: shorne_: Well, it looks like the c09635 assert is a sanity check to make sure we didn't do anything stupid, and well..... +(13:44:57) pm215: migration_incoming_get_current() and migration_incoming_state_destroy() seem a bit mismatched +(13:45:13) davidgiluk: pm215: Yep +(13:45:46) davidgiluk: pm215: Generally we've thought that an incoming migration normally only happens once - shorne_'s case is the exception +(13:46:03) shorne_: pm215: yeah, it looked something like that I just had a few seconds to look at today +(13:46:03) HariharanTS left the room (quit: Ping timeout: 480 seconds). +(13:46:03) shorne_ is now known as shorne +(13:48:05) shorne: davidgiluk: pm215: thanks for having a look. Unfortunately I need to head off to bed and put kids to sleep +(13:49:11) davidgiluk: shorne: Sleep well, no nightmares about event destroyers.... +(13:49:30) davidgiluk: pm215: Yeh this is fall out from b4b076daf32 + +Posted: +migration: Reset rather than destroy main_thread_load_event +snapshot/tests: Try loadvm twice + +Commit 5089e1862fe80b6f23ba4c494e2902cbe3d9d48e + diff --git a/results/classifier/118/graphic/1713 b/results/classifier/118/graphic/1713 new file mode 100644 index 000000000..a42211026 --- /dev/null +++ b/results/classifier/118/graphic/1713 @@ -0,0 +1,70 @@ +ppc: 0.966 +graphic: 0.926 +PID: 0.893 +device: 0.891 +performance: 0.877 +debug: 0.875 +user-level: 0.873 +arm: 0.865 +socket: 0.859 +peripherals: 0.843 +architecture: 0.836 +kernel: 0.832 +files: 0.829 +mistranslation: 0.826 +register: 0.814 +permissions: 0.780 +VMM: 0.779 +vnc: 0.772 +risc-v: 0.764 +network: 0.763 +semantic: 0.760 +i386: 0.752 +virtual: 0.724 +x86: 0.718 +hypervisor: 0.714 +boot: 0.706 +KVM: 0.652 +TCG: 0.642 +assembly: 0.624 + +hw/input/hid.c - Add Support for More Than Five Mouse Buttons in QEMU for evdev? +Additional information: +Sure enough, there appear to only be five buttons defined. + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/input/hid.c#L113 + +```c +[INPUT_BUTTON_LEFT] = 0x01, +[INPUT_BUTTON_RIGHT] = 0x02, +[INPUT_BUTTON_MIDDLE] = 0x04, +[INPUT_BUTTON_SIDE] = 0x08, +[INPUT_BUTTON_EXTRA] = 0x10, +``` + + +At this point, the existing naming schema cannot be continued... might I suggest: + +```c +[INPUT_BUTTON_SIX] = 0x??, +[INPUT_BUTTON_SEVEN] = 0x??, +[INPUT_BUTTON_EIGHT] = 0x??, +[INPUT_BUTTON_NINE] = 0x??, +[INPUT_BUTTON_TEN] = 0x??, +[INPUT_BUTTON_ELEVEN] = 0x??, +[INPUT_BUTTON_TWELVE] = 0x??, +``` +Although, I'm not sure if 12 buttons is future-proofed enough. + +I should also note that I found this post which states that there's no more space left in PS2 emulation, so I don't know if that would cause a conflict. +"ps/2 emulation looks like there are no unused bits for more buttons. Possibly we have to extend the usb mouse emulation for that." +https://listman.redhat.com/archives/vfio-users/2016-January/001596.html + +Unfortunately, I have never written a patch. I'm not even sure how I would apply a patch in Unraid, other than overwriting the bin file. So if this is ever fixed, I would simply hope that one day a new version of QEMU would get up-streamed into a new version of Unraid. + +So, here I am humbly asking for support. I don't know if it's as simple as just adding new definitions... and I have no idea what hex value to assign them. + +*edit* I also failed to get a temporary workaround to work by remapping the mouse buttons in the host VM using xmodmap using this command: + +`xmodmap -e "pointer = 1 12 3 4 5 6 7 8 9 10 11 2" &` +I tried saving `pointer = 1 12 3 4 5 6 7 8 9 10 11 2` in the host VM's root folder in .Xmodmap, but it did not propogate to guest VMs. The buttons were still their original mapping and running the xmod command had no effect. diff --git a/results/classifier/118/graphic/1713066 b/results/classifier/118/graphic/1713066 new file mode 100644 index 000000000..43345cd7c --- /dev/null +++ b/results/classifier/118/graphic/1713066 @@ -0,0 +1,95 @@ +graphic: 0.936 +peripherals: 0.930 +architecture: 0.928 +performance: 0.886 +files: 0.883 +device: 0.882 +network: 0.875 +semantic: 0.871 +register: 0.863 +permissions: 0.863 +socket: 0.856 +vnc: 0.847 +assembly: 0.841 +user-level: 0.839 +arm: 0.834 +mistranslation: 0.834 +debug: 0.832 +ppc: 0.816 +hypervisor: 0.810 +TCG: 0.809 +PID: 0.788 +boot: 0.782 +i386: 0.768 +risc-v: 0.754 +virtual: 0.728 +VMM: 0.724 +x86: 0.718 +kernel: 0.700 +KVM: 0.601 + +Incorrect handling of aarch64 ldp in some cases + +In some cases the ldp instruction (and presumably other multi-register loads and stores) can behave incorrectly. + +Given the following instruction: +ldp x0, x1, [x0] + +This will load two 64 bit values from memory, however if each location to load is on a different page and the second page is unmapped this will raise an exception. When this happens x0 has already been updated so after the exception handler has run the operating system will try to rerun the instruction. QEMU will now try to perform an invalid load and raise a new exception. + +I believe this is incorrect as section D.1.14.5 of the ARMv8 reference manual B.a states that, on taking an exception, registers used in the generation of addresses are restored to their initial value, so x0 shouldn't be changed, where x1 can be un an unknown state. + +I found the issue running FreeBSD with the cortex-strings implementation of memcpy. This uses a similar instruction when copying between 64 and 96 bytes. + +I've observed this on: +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.14), Copyright (c) 2003-2008 Fabrice Bellard + +And checked I still get the same behaviour on: +QEMU emulator version 2.9.94 (v2.10.0-rc4-dirty) +Git revision: 248b23735645f7cbb503d9be6f5bf825f2a603ab + +On 25 August 2017 at 14:50, Andrew <email address hidden> wrote: +> Given the following instruction: +> ldp x0, x1, [x0] +> +> This will load two 64 bit values from memory, however if each location +> to load is on a different page and the second page is unmapped this will +> raise an exception. When this happens x0 has already been updated + +Yes, this is a QEMU bug. disas_ldst_pair() should not let the +first load go directly to the target integer register but instead +postpone updating the register until after the second load. +We can safely do this only for the integer load case because +float/vector registers can't be used in address generation so +they're OK to become UNKNOWN. +(D1.14.5 is about interrupts and exceptions that happen during +a multiple-register load or store; for straightforward synchronous +data aborts D1.13.4 is what you want, but the requirements are the +same in any case.) + +We got this right for the load/store exclusive pair, so it's only +the plain load pair that needs fixing I think. + +thanks +-- PMM + + +This might be the cause for my bugreport: https://bugs.launchpad.net/qemu/+bug/1711316 + +Marked mine as a duplicate of this, please correct me if I'm wrong. + + +Yes, D1.13.4 is what I want, I'm not completely familiar with this part of the document. + +Based on my reading of gen_load_exclusive I agree that it looks correct, and loading to a float/vector won't affect the address generation. + +I have worked around this in FreeBSD my switching the order of the registers in the affected load & store, but still have an image I can test a fix with. + +Richard Henderson has posted a patch which should fix this: http://patchwork.ozlabs.org/patch/806051/ + + +That patch seems to have fixed the issue. I don't get the segfault I was previously getting without the patch. + +This fix has now been committed to master as commit 3e4d91b94ce400326fae0 and will be in QEMU 2.11 (and possibly in some stable releases before that). + + diff --git a/results/classifier/118/graphic/1714 b/results/classifier/118/graphic/1714 new file mode 100644 index 000000000..4e1883fa2 --- /dev/null +++ b/results/classifier/118/graphic/1714 @@ -0,0 +1,57 @@ +graphic: 0.904 +architecture: 0.866 +arm: 0.846 +device: 0.822 +performance: 0.702 +user-level: 0.670 +i386: 0.597 +ppc: 0.585 +x86: 0.556 +semantic: 0.552 +risc-v: 0.494 +socket: 0.479 +vnc: 0.477 +boot: 0.436 +TCG: 0.435 +hypervisor: 0.432 +register: 0.429 +debug: 0.425 +network: 0.421 +peripherals: 0.410 +permissions: 0.406 +PID: 0.404 +kernel: 0.375 +mistranslation: 0.312 +VMM: 0.307 +assembly: 0.243 +virtual: 0.242 +KVM: 0.207 +files: 0.192 + +QEMU crashes on ARMv7 since at least commit 493c9b19 +Description of problem: +I'm trying to build QEMU for Android, Arm64 versions work well, but **Armv7** builds began to crash nearly since this series of commits (QEMU 7.2.50), related to 'TCG_TARGET_HAS_direct_jump' removal by @rth7680. +More precisely, this commit still works: + +https://gitlab.com/qemu-project/qemu/-/commit/82df11e78d0baef7ffb7e7933c6fb830ffed087c + +and this one crashes: + +https://gitlab.com/qemu-project/qemu/-/commit/493c9b19a7fb7f387c4fcf57d3836504d5242bf5 + +(I tracked commits of 'tcg' subfolder and didn't bisect finer, but it's possible if needed). + +Both qemu-system-x86_64 and qemu-system-i386 emulators crash. + +**The crash is related to translation buffer size** : if I don't specify "-accel tcg,thread=single **,tb-size=256** ", the machine works. + +The problem is that I can not run debugger on a phone, and crash dump does not show any useful information, just "segfault" reason ("Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xe19b8000"). + +Even more, the Linux starts and runs, but it crashes only when I'm trying to run the GIMP, between splash screen and main interface appearance. + +I know that 1) Android is not officially supported and 2) 32-bit hosts were considered deprecated recently, but maybe it's possible to do something with these crashes? + +Recent master (https://gitlab.com/qemu-project/qemu/-/commit/5692a39f329413a00020a61fff95aff6b9884a73) doesn't work as well. +All 8.0.x Arm64 builds are runnable. + +Thanks in advance. diff --git a/results/classifier/118/graphic/1715 b/results/classifier/118/graphic/1715 new file mode 100644 index 000000000..36859dca9 --- /dev/null +++ b/results/classifier/118/graphic/1715 @@ -0,0 +1,31 @@ +graphic: 0.963 +semantic: 0.523 +device: 0.499 +performance: 0.494 +network: 0.401 +VMM: 0.355 +vnc: 0.337 +arm: 0.309 +boot: 0.274 +architecture: 0.264 +socket: 0.254 +virtual: 0.248 +ppc: 0.218 +register: 0.191 +TCG: 0.179 +mistranslation: 0.166 +hypervisor: 0.146 +x86: 0.137 +user-level: 0.130 +kernel: 0.130 +files: 0.128 +risc-v: 0.118 +debug: 0.111 +i386: 0.105 +permissions: 0.104 +assembly: 0.091 +PID: 0.075 +KVM: 0.044 +peripherals: 0.041 + +qemu-img convert about target_is_new diff --git a/results/classifier/118/graphic/1716132 b/results/classifier/118/graphic/1716132 new file mode 100644 index 000000000..d4a8cf9d0 --- /dev/null +++ b/results/classifier/118/graphic/1716132 @@ -0,0 +1,57 @@ +graphic: 0.934 +device: 0.899 +TCG: 0.852 +ppc: 0.843 +KVM: 0.833 +user-level: 0.821 +performance: 0.805 +boot: 0.797 +files: 0.752 +architecture: 0.750 +semantic: 0.733 +arm: 0.729 +kernel: 0.728 +PID: 0.710 +hypervisor: 0.708 +register: 0.707 +permissions: 0.705 +network: 0.701 +mistranslation: 0.700 +vnc: 0.689 +virtual: 0.689 +peripherals: 0.657 +x86: 0.653 +debug: 0.650 +risc-v: 0.645 +socket: 0.634 +i386: 0.574 +assembly: 0.569 +VMM: 0.564 + +Win 10 bitlocker won't initialise pass-through TPM + +All stock Ubuntu Zesty, Win10Pro KVM guest configured with OVMF and Q35. My host has an ASRock Z97 Extreme 6 board with a TPM header which is populated with v1.2 complaint device. + +Testing in my host the TPM device is function, I can tpm_takeownership and tpm_clear successfully and similar testing by passing the device through to a linux guest also succeeds. + +However using Bitlocker in Windows 10 Pro release 1703 Windows advises it cannot "Prepare" the device which I take to mean it cannot take ownership of it. I believe this to be related to Windows inability to view the TCG Event Log which is evidenced in the below 2 screencaps, however I'm no expert. + +https://s26.postimg.org/vter35eh5/Screenshot_20170907_114644.png +https://s26.postimg.org/klo854qyx/Screenshot_20170909_143841.png + +I've also tested the scenario with qemu 2.10 which provided the exact same results. The only difference in the test setup is that I had to make the guest boot with SeaBios instead of OVMF. (Windows wouldn't boot with OVMF with the boot manager giving me an error pointing to a BCD issue. Researching this it seemed related to an old ACPI problem, I believe this unrelated to my TPM issue so will do more research and raise a separate bug for this if needed.) + +Happy to provide further configurations and build logs as necessary so please advise me what is needed. + +Lastly for background reading. I've been trying to get TPM passthrough working with Windows for a long time now and have hit several different issues which I believe have been addressed by both code maturity in Qemu but also in Windows releases. An earlier bug report can be found here (https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1615722) which concludes advising me to raise this new/separate issue. + +Thanks in advance, + +Kelvin + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1717 b/results/classifier/118/graphic/1717 new file mode 100644 index 000000000..9bf8f5331 --- /dev/null +++ b/results/classifier/118/graphic/1717 @@ -0,0 +1,59 @@ +graphic: 0.973 +x86: 0.973 +kernel: 0.961 +device: 0.922 +architecture: 0.903 +debug: 0.896 +PID: 0.880 +peripherals: 0.833 +semantic: 0.825 +performance: 0.801 +virtual: 0.694 +permissions: 0.676 +mistranslation: 0.674 +vnc: 0.635 +hypervisor: 0.608 +user-level: 0.568 +register: 0.563 +risc-v: 0.560 +VMM: 0.547 +ppc: 0.492 +boot: 0.468 +i386: 0.409 +network: 0.388 +socket: 0.386 +KVM: 0.378 +TCG: 0.376 +assembly: 0.309 +files: 0.287 +arm: 0.281 + +GPU passthrough (NV h100)case vfio Error +Description of problem: +GPU passthrough (NV h100) will case a error + + +qemu-system-x86_64: vfio_err_notifier_handler(0000:17:00.0) Unrecoverable error detected. Please collect any data possible and then kill the guest + + +this error happen in centos, redhat linux,ubuntu with some kernel i have try( 5.19.0,6.0,6.2) +The same server insert L4,L40 GPU, will not happen. Only happen on H100 GPU +The same server install esxios. everything is normal. GPU work fine + +With vfio error. there is some idrac log error on my dell server + +``` +A bus fatal error was detected on a component at slot 2. Tue Jun 20 2023 05:51:51 +A fatal error was detected on a component at bus 23 device 0 function 0. Tue Jun 20 2023 05:51:51 +A fatal error was detected on a component at bus 22 device 2 function 0. Tue Jun 20 2023 05:51:51 +``` + +Otherwise, I have try to passthrough gpu on dell amd and intel server both. +With AMD CPU , gpu not working in vm. but will not case vfio error +With INTEL CPU, will case vfio error. +Steps to reproduce: +1. Set GPU passthrought +2. Start VM +3. Do something in vm +Additional information: + diff --git a/results/classifier/118/graphic/1717414 b/results/classifier/118/graphic/1717414 new file mode 100644 index 000000000..961bddda6 --- /dev/null +++ b/results/classifier/118/graphic/1717414 @@ -0,0 +1,65 @@ +graphic: 0.810 +vnc: 0.727 +user-level: 0.709 +device: 0.662 +semantic: 0.615 +arm: 0.609 +network: 0.578 +permissions: 0.564 +performance: 0.554 +socket: 0.521 +virtual: 0.505 +PID: 0.479 +register: 0.446 +ppc: 0.435 +debug: 0.412 +mistranslation: 0.389 +hypervisor: 0.386 +peripherals: 0.372 +kernel: 0.337 +risc-v: 0.317 +architecture: 0.309 +files: 0.305 +assembly: 0.301 +VMM: 0.297 +boot: 0.294 +KVM: 0.268 +TCG: 0.224 +i386: 0.215 +x86: 0.195 + +Sending certain keysyms results in wrong symbol input + +I develop bVNC, an Android VNC client. I noticed that when I connect to qemu VMs that have a VNC console, Keysyms that are usually sent over with SHIFT modifier when connecting from a PC have wrong symbols typed within the VM. A very short list of examples: + +exclam 33 0x0021 + +results in "1" typed in the VM. + +at 64 0x0040 + +results in "2" + +plus 43 0x002b + +results in "=" + +asterisk 42 0x002a + +results in "8" + +On Android, KEYCODEs that correspond to the above keysyms do not come with SHIFT metastate. Therefore, the keysyms that they correspond to are not sent over with any modifiers and must just work. + +The issue was reproduced with bVNC and RealVNC viewers connecting to many versions of qemu (Ubuntu 14.04, oVirt 3.4, oVirt 4.1, etc.). The qemu version that comes with oVirt 4.1 is 2.6.0, commit hash bfc766d38e1fae5767d43845c15c79ac8fa6d6af. + +Sincerely, +iordan + +There have been quite a bunch of improvements in the keysyms handling during the past years ... can you still reproduce your issue with the latest version of QEMU? + +Seems to work fine now. Thank you!! + +iordan + +Thanks for testing! So I'm closing the ticket now. + diff --git a/results/classifier/118/graphic/1718964 b/results/classifier/118/graphic/1718964 new file mode 100644 index 000000000..1e0f04948 --- /dev/null +++ b/results/classifier/118/graphic/1718964 @@ -0,0 +1,147 @@ +graphic: 0.905 +semantic: 0.871 +KVM: 0.861 +user-level: 0.860 +performance: 0.852 +ppc: 0.850 +risc-v: 0.843 +mistranslation: 0.835 +register: 0.835 +VMM: 0.821 +debug: 0.812 +network: 0.811 +assembly: 0.807 +virtual: 0.807 +PID: 0.805 +permissions: 0.801 +device: 0.801 +peripherals: 0.788 +TCG: 0.782 +vnc: 0.777 +hypervisor: 0.777 +architecture: 0.766 +files: 0.751 +arm: 0.716 +x86: 0.715 +boot: 0.695 +socket: 0.669 +kernel: 0.663 +i386: 0.441 + +Memory leak when using websocket over a low speed network + +Description of problem +------------------------- + +When VNC is connected to QEMU via websocket over a low speed network (e.g. 300KB/S Wide Area Network), and there is a lot of frame buffer update, the VNC Client will get stuck, the cursor is almost impossible to move, which may result in accumulation of a large number of data in the QEMU process (memory consumption will keep increasing). + + +Environment +------------------------- +All of the following versions have been tested: + +QEMU: 2.5.1 / 2.6.0 / 2.8.1.1 / 2.9.0 / 2.10.0 +Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611 +Guest OS: Windows 7 64bit / Ubuntu 16.04 Desktop LTS +Client OS: Windows 7 64bit / Windows 10 64bit +Client Browser: IE 11.0.9600 / Chrome 60.0.3112 / Firefox 55.0.2 +VNC Client: TigerVNC Viewer 1.8 / UltraVNC Viewer 1.2.1.5 / TightVNC Viewer 2.8.8 +VNC Web Client: noVNC 0.5.1 / noVNC 0.61 / noVNC 0.62 +VNC Server: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8 +VNC Client: TigerVNC Viewer 1.8 / UltraVNC Viewer 1.2.1.5 / TightVNC Viewer 2.8.8 + + +Steps to reproduce: +------------------------- +100% reproducible. + +1. Launch a QEMU instance with websocket option: +qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :1,websocket=5701 + +2. Open VNC Web Client (noVNC/vnc.html) in browser and connect to QEMU VM via websocket + +3. Play a video (e.g. Watch YouTube) on VM (To produce a lot of frame buffer update) + +4. Limit (e.g. Use NetLimiter) the client inbound bandwidth to 300KB/S (To simulate a low speed WAN) + +5. Then client's output gets stuck(less than 1 fps), the cursor is almost impossible to move + +6. Observe QEMU process on the host, more and more data are accumulated in the process, the consumption of memory continues to keep increasing + + +Current result: +------------------------- +[Top - Initial status] + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 2725 root 20 0 7229144 5.910g 23024 S 16.3 18.9 0:12.84 qemu-system-x86_64 + +[Top - After an hour's playing w/o limit (6-8MB/S)] + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 2725 root 20 0 7370284 6.046g 23132 S 28.0 19.3 35:58.15 qemu-system-x86_64 + +[Top - Limit the bandwidth and continue to playing for another an hour (300KB/S)] + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 2725 root 20 0 11.029g 8.853g 23132 S 20.0 28.2 72:14.17 qemu-system-x86_64 + +Also test several other combinations in the same environment: + +1. Client(VNC Viewer) - Server(QEMU) +2. Client(VNC Viewer) - Server(tigervnc/x11vnc/tightvnc) +3. Client(noVNC) - Server(tigervnc/x11vnc/tightvnc) + +Likewise, the client's inbound bandwidth is limited to 300KB/S, +although a lot of frame are lost, all of they still works (at least the mouse is movable). + +It's found that when connect to QEMU via websocket, it never drop any frames. +QEMU still sends a lot of data to its websocket even when the network is congested, +the process is continually consuming more memory, then it gets stack. + + +Expected results: +------------------------- +When the network is poor (non-LAN), QEMU would reduce the VNC data send to its websocket correspondingly, and the memory usage remains stable. + +Thanks for your report. I've not tried reproducing yet, but from the looking at the code I think I can see why this happens. Code in vnc_update_client discards incoming frame updates from the guest if the output buffer has data pending in it, but it only checks the main VNC server output buffer usage. It fails to check the websockets output buffer usage. + +In the modern code this needs fixing in the io/channel-websock.c impl - it is checking the output buffer limit against the wrong buffer - it uses 'rawoutput' instead of 'encoutput', so this fix is easy enough there. + +The code is in fact broken all the way back to day1 of the introduction of websockets support though in QEMU 1.2.1 In the historical code it can be fixed by checking ws_output.offset in vnc_update_client as I mentioned previously + +We are experiencing the same problem. + +At first, we thought the bug is in QEMU's websocket code then we tried using a standalone websocket proxy (websockify). Unfortunately, problems persisted. + +We also tried various other VNC servers (with websockify), all of them work fine. It seems that the issue is specific to QEMU. + +This has been assigned CVE-2017-15268 + +http://www.openwall.com/lists/oss-security/2017/10/12/4 + +commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493 +Author: Daniel P. Berrange <email address hidden> +Date: Mon Oct 9 14:43:42 2017 +0100 + + io: monitor encoutput buffer size from websocket GSource + + The websocket GSource is monitoring the size of the rawoutput + buffer to determine if the channel can accepts more writes. + The rawoutput buffer, however, is merely a temporary staging + buffer before data is copied into the encoutput buffer. Thus + its size will always be zero when the GSource runs. + + This flaw causes the encoutput buffer to grow without bound + if the other end of the underlying data channel doesn't + read data being sent. This can be seen with VNC if a client + is on a slow WAN link and the guest OS is sending many screen + updates. A malicious VNC client can act like it is on a slow + link by playing a video in the guest and then reading data + very slowly, causing QEMU host memory to expand arbitrarily. + + This issue is assigned CVE-2017-15268, publically reported in + + https://bugs.launchpad.net/qemu/+bug/1718964 + + Reviewed-by: Eric Blake <email address hidden> + Signed-off-by: Daniel P. Berrange <email address hidden> + + diff --git a/results/classifier/118/graphic/1719196 b/results/classifier/118/graphic/1719196 new file mode 100644 index 000000000..2f313457b --- /dev/null +++ b/results/classifier/118/graphic/1719196 @@ -0,0 +1,766 @@ +register: 0.959 +graphic: 0.958 +debug: 0.954 +virtual: 0.953 +permissions: 0.944 +semantic: 0.943 +device: 0.931 +assembly: 0.924 +performance: 0.924 +user-level: 0.913 +architecture: 0.910 +network: 0.907 +mistranslation: 0.899 +arm: 0.899 +PID: 0.894 +files: 0.845 +boot: 0.842 +peripherals: 0.829 +ppc: 0.797 +VMM: 0.782 +kernel: 0.765 +TCG: 0.759 +vnc: 0.754 +KVM: 0.750 +socket: 0.736 +hypervisor: 0.735 +x86: 0.725 +risc-v: 0.682 +i386: 0.641 + +[arm64 ocata] newly created instances are unable to raise network interfaces + +arm64 Ocata , + +I'm testing to see I can get Ocata running on arm64 and using the openstack-base bundle to deploy it. I have added the bundle to the log file attached to this bug. + +When I create a new instance via nova, the VM comes up and runs, however fails to raise its eth0 interface. This occurs on both internal and external networks. + +ubuntu@openstackaw:~$ nova list ++--------------------------------------+---------+--------+------------+-------------+--------------------+ +| ID | Name | Status | Task State | Power State | Networks | ++--------------------------------------+---------+--------+------------+-------------+--------------------+ +| dcaf6d51-f81e-4cbd-ac77-0c5d21bde57c | sfeole1 | ACTIVE | - | Running | internal=10.5.5.3 | +| aa0b8aee-5650-41f4-8fa0-aeccdc763425 | sfeole2 | ACTIVE | - | Running | internal=10.5.5.13 | ++--------------------------------------+---------+--------+------------+-------------+--------------------+ +ubuntu@openstackaw:~$ nova show aa0b8aee-5650-41f4-8fa0-aeccdc763425 ++--------------------------------------+----------------------------------------------------------+ +| Property | Value | ++--------------------------------------+----------------------------------------------------------+ +| OS-DCF:diskConfig | MANUAL | +| OS-EXT-AZ:availability_zone | nova | +| OS-EXT-SRV-ATTR:host | awrep3 | +| OS-EXT-SRV-ATTR:hypervisor_hostname | awrep3.maas | +| OS-EXT-SRV-ATTR:instance_name | instance-00000003 | +| OS-EXT-STS:power_state | 1 | +| OS-EXT-STS:task_state | - | +| OS-EXT-STS:vm_state | active | +| OS-SRV-USG:launched_at | 2017-09-24T14:23:08.000000 | +| OS-SRV-USG:terminated_at | - | +| accessIPv4 | | +| accessIPv6 | | +| config_drive | | +| created | 2017-09-24T14:22:41Z | +| flavor | m1.small (717660ae-0440-4b19-a762-ffeb32a0575c) | +| hostId | 5612a00671c47255d2ebd6737a64ec9bd3a5866d1233ecf3e988b025 | +| id | aa0b8aee-5650-41f4-8fa0-aeccdc763425 | +| image | zestynosplash (e88fd1bd-f040-44d8-9e7c-c462ccf4b945) | +| internal network | 10.5.5.13 | +| key_name | mykey | +| metadata | {} | +| name | sfeole2 | +| os-extended-volumes:volumes_attached | [] | +| progress | 0 | +| security_groups | default | +| status | ACTIVE | +| tenant_id | 9f7a21c1ad264fec81abc09f3960ad1d | +| updated | 2017-09-24T14:23:09Z | +| user_id | e6bb6f5178a248c1b5ae66ed388f9040 | ++--------------------------------------+----------------------------------------------------------+ + + + +As seen above the instances boot an run. Full Console output is attached to this bug. + + +[ OK ] Started Initial cloud-init job (pre-networking). +[ OK ] Reached target Network (Pre). +[ OK ] Started AppArmor initialization. + Starting Raise network interfaces... +[FAILED] Failed to start Raise network interfaces. +See 'systemctl status networking.service' for details. + Starting Initial cloud-init job (metadata service crawler)... +[ OK ] Reached target Network. +[ 315.051902] cloud-init[881]: Cloud-init v. 0.7.9 running 'init' at Fri, 22 Sep 2017 18:29:15 +0000. Up 314.70 seconds. +[ 315.057291] cloud-init[881]: ci-info: +++++++++++++++++++++++++++Net device info+++++++++++++++++++++++++++ +[ 315.060338] cloud-init[881]: ci-info: +--------+------+-----------+-----------+-------+-------------------+ +[ 315.063308] cloud-init[881]: ci-info: | Device | Up | Address | Mask | Scope | Hw-Address | +[ 315.066304] cloud-init[881]: ci-info: +--------+------+-----------+-----------+-------+-------------------+ +[ 315.069303] cloud-init[881]: ci-info: | eth0: | True | . | . | . | fa:16:3e:39:4c:48 | +[ 315.072308] cloud-init[881]: ci-info: | eth0: | True | . | . | d | fa:16:3e:39:4c:48 | +[ 315.075260] cloud-init[881]: ci-info: | lo: | True | 127.0.0.1 | 255.0.0.0 | . | . | +[ 315.078258] cloud-init[881]: ci-info: | lo: | True | . | . | d | . | +[ 315.081249] cloud-init[881]: ci-info: +--------+------+-----------+-----------+-------+-------------------+ +[ 315.084240] cloud-init[881]: 2017-09-22 18:29:15,393 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0xffffb10794e0>: Failed to establish a new connection: [Errno 101] Network is unreachable',))] + + + + +---------------- + + + +I have checked all services in neutron and made sure that they are running and restarted in neutron-gateway + + + [ + ] neutron-dhcp-agent + [ + ] neutron-l3-agent + [ + ] neutron-lbaasv2-agent + [ + ] neutron-metadata-agent + [ + ] neutron-metering-agent + [ + ] neutron-openvswitch-agent + [ + ] neutron-ovs-cleanup + +and have also restarted and checked the nova-compute logs for their neutron counterparts. + + + [ + ] neutron-openvswitch-agent + [ + ] neutron-ovs-cleanup + + + + There are some warnings/errors in the neutron-gateway logs which I have attached the full tarball in a separate attachment to this bug: + +2017-09-24 14:39:33.152 10322 INFO ryu.base.app_manager [-] instantiating app ryu.controller.ofp_handler of OFPHandler +2017-09-24 14:39:33.153 10322 INFO ryu.base.app_manager [-] instantiating app ryu.app.ofctl.service of OfctlService +2017-09-24 14:39:39.577 10322 ERROR neutron.agent.ovsdb.impl_vsctl [req-2f084ae8-13dc-47dc-b351-24c8f3c57067 - - - - -] Unable to execute ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', '--id=@manager', 'create', 'Manager', 'target="ptcp:6640:127.0.0.1"', '--', 'add', 'Open_vSwitch', '.', 'manager_options', '@manager']. Exception: Exit code: 1; Stdin: ; Stdout: ; Stderr: ovs-vsctl: transaction error: {"details":"Transaction causes multiple rows in \"Manager\" table to have identical values (\"ptcp:6640:127.0.0.1\") for index on column \"target\". First row, with UUID e02a5f7f-bfd2-4a1d-ae3c-0321db4bd3fb, existed in the database before this transaction and was not modified by the transaction. Second row, with UUID 6e9aba3a-471a-4976-bffd-b7131bbe5377, was inserted by this transaction.","error":"constraint violation"} + + + +These warnings/errors also occur on the nova-compute hosts in /var/log/neutron/ + + + + +2017-09-22 18:54:52.130 387556 INFO ryu.base.app_manager [-] instantiating app ryu.app.ofctl.service of OfctlService +2017-09-22 18:54:56.124 387556 ERROR neutron.agent.ovsdb.impl_vsctl [req-e291c2f9-a123-422c-be7c-fadaeb5decfa - - - - -] Unable to execute ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', '--id=@manager', 'create', 'Manager', 'target="ptcp:6640:127.0.0.1"', '--', 'add', 'Open_vSwitch', '.', 'manager_options', '@manager']. Exception: Exit code: 1; Stdin: ; Stdout: ; Stderr: ovs-vsctl: transaction error: {"details":"Transaction causes multiple rows in \"Manager\" table to have identical values (\"ptcp:6640:127.0.0.1\") for index on column \"target\". First row, with UUID 9f27ddee-9881-4cbc-9777-2f42fee735e9, was inserted by this transaction. Second row, with UUID ccf0e097-09d5-449c-b353-6b69781dc3f7, existed in the database before this transaction and was not modified by the transaction.","error":"constraint violation"} + + + +I'm not sure if the above error could be pertaining to the failure, I have also attached those logs to this bug as well... + + +. +(neutron) agent-list ++--------------------------------------+----------------------+--------+-------------------+-------+----------------+---------------------------+ +| id | agent_type | host | availability_zone | alive | admin_state_up | binary | ++--------------------------------------+----------------------+--------+-------------------+-------+----------------+---------------------------+ +| 0cca03fb-abb2-4704-8b0b-e7d3e117d882 | DHCP agent | awrep1 | nova | :-) | True | neutron-dhcp-agent | +| 14a5fd52-fbc3-450c-96d5-4e9a65776dad | L3 agent | awrep1 | nova | :-) | True | neutron-l3-agent | +| 2ebc7238-5e61-41f8-bc60-df14ec6b226b | Loadbalancerv2 agent | awrep1 | | :-) | True | neutron-lbaasv2-agent | +| 4f6275be-fc8b-4994-bdac-13a4b76f6a83 | Metering agent | awrep1 | | :-) | True | neutron-metering-agent | +| 86ecc6b0-c100-4298-b861-40c17516cc08 | Open vSwitch agent | awrep1 | | :-) | True | neutron-openvswitch-agent | +| 947ad3ab-650b-4b96-a520-00441ecb33e7 | Open vSwitch agent | awrep4 | | :-) | True | neutron-openvswitch-agent | +| 996b0692-7d19-4641-bec3-e057f4a856f6 | Open vSwitch agent | awrep3 | | :-) | True | neutron-openvswitch-agent | +| ab6b1065-0b98-4cf3-9f46-6bddba0c5e75 | Metadata agent | awrep1 | | :-) | True | neutron-metadata-agent | +| fe24f622-b77c-4eed-ae22-18e4195cf763 | Open vSwitch agent | awrep2 | | :-) | True | neutron-openvswitch-agent | ++--------------------------------------+----------------------+--------+-------------------+-------+----------------+---------------------------+ + + +Should neutron-openvswitch be assigned to the 'nova' availability zone? + +I have also attached the ovs-vsctl show from a nova-compute host and the neutron-gateway host to ensure that the open v switch routes are correct. + + +I can supply more logs if required. + + + + + + + + + +juju status +bundle file +vm console output +and nova service list + +can be found in ocata-arm64-neutronbug.txt + +Running tcpdump on the guests tap device shows the dhcp request leaving and the reply coming back. + +This may be qemu related, rather than libvirt - further investigation required - but unlikely to be a problem with neutron-gateway charm + +I have confirmed this bug with another arm64 + ocata deployment. + +Further summary: + +we can see dhcp requests leaving and returning to the tap interface associated with the guest, but the guest does not register the returned packet (does not acquire an address). + +I was also able to reproduce this again on Cavium ThunderX hardware, + + +ii ipxe-qemu 1.0.0+git-20150424.a25a16d-1ubuntu1 all PXE boot firmware - ROM images for qemu +ii qemu-block-extra:arm64 1:2.8+dfsg-3ubuntu2.3~cloud0 arm64 extra block backend modules for qemu-system and qemu-utils +ii qemu-efi 0~20160408.ffea0a2c-2 all UEFI firmware for virtual machines +ii qemu-kvm 1:2.8+dfsg-3ubuntu2.3~cloud0 arm64 QEMU Full virtualization +ii qemu-system-arm 1:2.8+dfsg-3ubuntu2.3~cloud0 arm64 QEMU full system emulation binaries (arm) +ii qemu-system-common 1:2.8+dfsg-3ubuntu2.3~cloud0 arm64 QEMU full system emulation binaries (common files) +ii qemu-utils 1:2.8+dfsg-3ubuntu2.3~cloud0 arm64 QEMU utilities + + +------------------- + +ii libvirt-bin 2.5.0-3ubuntu5.4~cloud0 arm64 programs for the libvirt library +ii libvirt-clients 2.5.0-3ubuntu5.4~cloud0 arm64 Programs for the libvirt library +ii libvirt-daemon 2.5.0-3ubuntu5.4~cloud0 arm64 Virtualization daemon +ii libvirt-daemon-system 2.5.0-3ubuntu5.4~cloud0 arm64 Libvirt daemon configuration files +ii libvirt0:arm64 2.5.0-3ubuntu5.4~cloud0 arm64 library for interfacing with different virtualization systems +ii nova-compute-libvirt 2:15.0.6-0ubuntu1~cloud0 all OpenStack Compute - compute node libvirt support +ii python-libvirt 3.0.0-2~cloud0 arm64 libvirt Python bindings + + +Just to further add to comment #6, That this is not a neutron issue, Here is the tcpdump output of the guests tap device shows the dhcp request leaving and the reply coming back. For anyways that may be curious. + + +Guest MAC: + + <interface type='bridge'> + <mac address='fa:16:3e:1d:a8:82'/> + <source bridge='qbrc8faaf66-7f'/> + <target dev='tapc8faaf66-7f'/> + <model type='virtio'/> + <address type='virtio-mmio'/> + </interface> + + + +$ sudo ip netns exec qdhcp-a9958ab4-8a7e-4ded-b9a0-860bc42f79d9 tcpdump -A -l -i ns-c751afb3-2b +tcpdump: verbose output suppressed, use -v or -vv for full protocol decode +listening on ns-c751afb3-2b, link-type EN10MB (Ethernet), capture size 262144 bytes +13:51:11.458941 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 +`....$..................................:................................... +13:51:11.462966 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:1d:a8:82 (oui Unknown), length 300 +E..H......9..........D.C.4q.....5QN{......................>.............................................................................................................................................................................................................c.Sc5....ubuntu7.......w.,/.y*.................................. +13:51:11.463331 IP 10.5.5.2.bootps > 10.5.5.9.bootpc: BOOTP/DHCP, Reply, length 328 +E..dY'..@... + + + + +Today I ran some tests and installed a Newton Deployment on arm64, which we already know works. I upgraded QEMU and Libvirt on one of the hypervisors from the xenial-updates/ocata cloud-archive. + +See attached notes. + +Libvirt - 1.3.1-1ubuntu10.14 -> 2.5.0-3ubuntu5.5~cloud0 +QEMU - 1:2.5+dfsg-5ubuntu10.16 -> 1:2.8+dfsg-3ubuntu2.3~cloud0 + +I was able to reset the already built instance on the hypervisor and was able to receive a dhcp response from the ovs tap device. Eth0 came up as expected with an internal tenant IP. + + +Steps to reproduce. + +1.) Install Newton & start a few VM's +2.) Choose 1 hypervisor , upgrade qemu & libvirt to versions from the Ocata cloud-archive. +3.) Reset the running VM so that it now runs with the latest QEMU/Libvirt +4.) Reset the Instance, see if it boots and network can be reached. + + + +Taken from the upgraded hypervisor: + +ubuntu@awrep3:/var/lib/nova/instances/2cec409e-de92-4d29-ad68-3f1d1f8be7fc$ sudo qemu-system-aarch64 --version +QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-3ubuntu2.3~cloud0) +Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers + + +ubuntu@awrep3:/var/lib/nova/instances/2cec409e-de92-4d29-ad68-3f1d1f8be7fc$ sudo libvirtd --version +libvirtd (libvirt) 2.5.0 + + +Taken from the upgraded hypervisor + +ubuntu@aw3:/var/lib/nova/instances/2cec409e-de92-4d29-ad68-3f1d1f8be7fc$ sudo qemu-system-aarch64 --version +QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-3ubuntu2.3~cloud0) +Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers + + +ubuntu@aw3:/var/lib/nova/instances/2cec409e-de92-4d29-ad68-3f1d1f8be7fc$ sudo libvirtd --version +libvirtd (libvirt) 2.5.0 + + +I was able to gather libvirt XMLs from both Newton and Ocata Instances, see attached + +sfeole@BSG-75:~$ diff xmlocata xmlnewton +1,2c1,2 +< +< main type='kvm' id='1'> +--- +> ubuntu@lundmark:/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c$ sudo virsh dumpxml instance-00000001 +> <domain type='kvm' id='1'> +4c4 +< <uuid>7c0dcd78-d6b4-4575-a882-ee5d29c64fe0</uuid> +--- +> <uuid>358596e4-135d-461d-a514-84116440014c</uuid> +7,9c7,9 +< <nova:package version="15.0.6"/> +< <nova:name>sfeole14</nova:name> +< <nova:creationTime>2017-10-05 00:58:15</nova:creationTime> +--- +> <nova:package version="14.0.8"/> +> <nova:name>sfeole-newton</nova:name> +> <nova:creationTime>2017-10-05 01:40:39</nova:creationTime> +18,19c18,19 +< <nova:user uuid="d9f92a61c37948d9a29b8cc37e1bca05">admin</nova:user> +< <nova:project uuid="701441267bd148d3842f1696530b1c92">admin</nova:project> +--- +> <nova:user uuid="12d13712253141ab845b89406507cd6c">admin</nova:user> +> <nova:project uuid="8b8fcaf183954f45b3eb15b27c52ec94">admin</nova:project> +21c21 +< <nova:root type="image" uuid="f329117f-5da2-4d61-8341-89a969bf00e7"/> +--- +> <nova:root type="image" uuid="fcdf7c26-4238-4594-b8ee-fd59f601fdcb"/> +34c34 +< <type arch='aarch64' machine='virt-2.8'>hvm</type> +--- +> <type arch='aarch64' machine='virt'>hvm</type> +58c58 +< <source file='/var/lib/nova/instances/7c0dcd78-d6b4-4575-a882-ee5d29c64fe0/disk'/> +--- +> <source file='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/disk'/> +61c61 +< <source file='/var/lib/nova/instances/_base/035458feead7f83be80ed020442ebf815a4067ea'/> +--- +> <source file='/var/lib/nova/instances/_base/ab7429e8558ea27fb54f70eb92fbd0c1c07dd595'/> +70c70 +< <source file='/var/lib/nova/instances/7c0dcd78-d6b4-4575-a882-ee5d29c64fe0/disk.eph0'/> +--- +> <source file='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/disk.eph0'/> +82a83,93 +> <controller type='pci' index='1' model='dmi-to-pci-bridge'> +> <model name='i82801b11-bridge'/> +> <alias name='pci.1'/> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> +> </controller> +> <controller type='pci' index='2' model='pci-bridge'> +> <model name='pci-bridge'/> +> <target chassisNr='2'/> +> <alias name='pci.2'/> +> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> +> </controller> +84,86c95,97 +< <mac address='fa:16:3e:a6:4b:d4'/> +< <source bridge='qbra7012530-32'/> +< <target dev='tapa7012530-32'/> +--- +> <mac address='fa:16:3e:8e:fc:48'/> +> <source bridge='qbrb5d335fc-46'/> +> <target dev='tapb5d335fc-46'/> +92c103 +< <source path='/var/lib/nova/instances/7c0dcd78-d6b4-4575-a882-ee5d29c64fe0/console.log'/> +--- +> <source path='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/console.log'/> +95a107,111 +> <serial type='pty'> +> <source path='/dev/pts/3'/> +> <target port='1'/> +> <alias name='serial1'/> +> </serial> +97c113 +< <source path='/var/lib/nova/instances/7c0dcd78-d6b4-4575-a882-ee5d29c64fe0/console.log'/> +--- +> <source path='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/console.log'/> +108,113c124,125 +< <label>libvirt-7c0dcd78-d6b4-4575-a882-ee5d29c64fe0</label> +< <imagelabel>libvirt-7c0dcd78-d6b4-4575-a882-ee5d29c64fe0</imagelabel> +< </seclabel> +< <seclabel type='dynamic' model='dac' relabel='yes'> +< <label>+64055:+117</label> +< <imagelabel>+64055:+117</imagelabel> +--- +> <label>libvirt-358596e4-135d-461d-a514-84116440014c</label> +> <imagelabel>libvirt-358596e4-135d-461d-a514-84116440014c</imagelabel> +sfeole@BSG-75:~$ + + +Thanks so much for doing that Sean. + +Omitting expected changes (uuid, mac address, etc), here's are the significant changes I see: + +1) N uses the QEMU 'virt' model, O uses 'virt-2.8' +2) N and O both expose a pci root, but N also exposed 2 PCI bridges that O does not. +3) N exposes an additional serial device. +4) N and O both use an apparmor seclabel. However, O also has a DAC model. + +#4 is the most interesting to me. Is there a way to configure ocata nova to not enable DAC? + +Hi, +I was reading into this after being back from PTO (actually back next monday). +I was wondering as I tested (without openstack) just that last week with Dannf on the Rally). +And indeed it seems to work for me on Artful (which as we all know is =Ocata in terms of SW stack). + +$ cat arm-template.xml +<domain type='kvm'> + <os> + <type arch='aarch64' machine='virt'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/AAVMF/AAVMF_CODE.fd</loader> + <nvram template='/usr/share/AAVMF/AAVMF_CODE.fd'>/tmp/AAVMF_CODE.fd</nvram> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <cpu mode='custom' match='exact'> + <model fallback='allow'>host</model> + </cpu> + <devices> + <interface type='network'> + <source network='default'/> + <model type='virtio'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/3'/> + <target port='0'/> + </serial> + </devices> +</domain> + +$ uvt-kvm create --template arm-template.xml --password=ubuntu artful-test4 release=artful arch=arm64 label=daily + +The template is created in a way to let as much as possible for libvirt and qemu to fill in defaults. That way if one of them change we do not have to follow and adapt. +Maybe such a thing is happening to you for the more "defined" xml that openstack is sending. + +From the hosts point of view all looks normal in journal, you see start and dhcp discover/offer/ack sequence: +Okt 11 10:45:43 seidel kernel: virbr0: port 2(vnet0) entered learning state +Okt 11 10:45:45 seidel kernel: virbr0: port 2(vnet0) entered forwarding state +Okt 11 10:45:45 seidel kernel: virbr0: topology change detected, propagating +Okt 11 10:46:14 seidel dnsmasq-dhcp[2610]: DHCPDISCOVER(virbr0) 52:54:00:b1:db:89 +Okt 11 10:46:14 seidel dnsmasq-dhcp[2610]: DHCPOFFER(virbr0) 192.168.122.13 52:54:00:b1:db:89 +Okt 11 10:46:14 seidel dnsmasq-dhcp[2610]: DHCPDISCOVER(virbr0) 52:54:00:b1:db:89 +Okt 11 10:46:14 seidel dnsmasq-dhcp[2610]: DHCPOFFER(virbr0) 192.168.122.13 52:54:00:b1:db:89 +Okt 11 10:46:14 seidel dnsmasq-dhcp[2610]: DHCPREQUEST(virbr0) 192.168.122.13 52:54:00:b1:db:89 +Okt 11 10:46:14 seidel dnsmasq-dhcp[2610]: DHCPACK(virbr0) 192.168.122.13 52:54:00:b1:db:89 ubuntu + +The guest also seems "normal" to me: +$ uvt-kvm ssh artful-test4 -- journalctl -u systemd-networkd +-- Logs begin at Wed 2017-10-11 10:46:03 UTC, end at Wed 2017-10-11 11:02:31 UTC. -- +Oct 11 10:46:11 ubuntu systemd[1]: Starting Network Service... +Oct 11 10:46:11 ubuntu systemd-networkd[547]: Enumeration completed +Oct 11 10:46:11 ubuntu systemd[1]: Started Network Service. +Oct 11 10:46:11 ubuntu systemd-networkd[547]: enp1s0: IPv6 successfully enabled +Oct 11 10:46:11 ubuntu systemd-networkd[547]: enp1s0: Gained carrier +Oct 11 10:46:12 ubuntu systemd-networkd[547]: enp1s0: Gained IPv6LL +Oct 11 10:46:14 ubuntu systemd-networkd[547]: enp1s0: DHCPv4 address 192.168.122.13/24 via 192.168.122.1 +Oct 11 10:46:14 ubuntu systemd-networkd[547]: Not connected to system bus, ignoring transient hostname. +Oct 11 10:46:24 ubuntu systemd-networkd[547]: enp1s0: Configured + +The biggest and obviously most important difference is in the networking that is used: + <interface type='network'> + <mac address='52:54:00:b1:db:89'/> + <source network='default' bridge='virbr0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </interface> + +While openstack generates a type="bridge" network where the bridge is not managed by libvirt (compared to the default net I use). +Never the less both setups create a bridge and tap the guest on it. +So this should functionally be equivalent other than the bridge setup right? + + +I tried to make a bridge type config matching to what I had before but close to yours: + <interface type='bridge'> + <mac address='52:54:00:b1:db:89'/> + <source bridge='virbr0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='virtio-mmio'/> + </interface> + +But this again works: +ubuntu@artful-test4:~$ journalctl -u systemd-networkd --no-pager +-- Logs begin at Wed 2017-10-11 11:12:10 UTC, end at Wed 2017-10-11 11:13:00 UTC. -- +Oct 11 11:12:17 artful-test4 systemd[1]: Starting Network Service... +Oct 11 11:12:17 artful-test4 systemd-networkd[604]: Enumeration completed +Oct 11 11:12:17 artful-test4 systemd[1]: Started Network Service. +Oct 11 11:12:17 artful-test4 systemd-networkd[604]: enp1s0: IPv6 successfully enabled +Oct 11 11:12:17 artful-test4 systemd-networkd[604]: enp1s0: Gained carrier +Oct 11 11:12:18 artful-test4 systemd-networkd[604]: enp1s0: Gained IPv6LL +Oct 11 11:12:20 artful-test4 systemd-networkd[604]: enp1s0: DHCPv4 address 192.168.122.14/24 via 192.168.122.1 +Oct 11 11:12:20 artful-test4 systemd-networkd[604]: Not connected to system bus, ignoring transient hostname. +Oct 11 11:12:30 artful-test4 systemd-networkd[604]: enp1s0: Configured + +Dumping the XML to check if it might have rewritten a lot shows me that my config is good: + <interface type='bridge'> + <mac address='52:54:00:b1:db:89'/> + <source bridge='virbr0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='virtio-mmio'/> + </interface> + +So TL;DR a config almost the same as yours works. +Yet the difference is that livbirt has set up 'virbr0' in my case and I'd assume openstack did create qbrb5d335fc-46 on its own. + +As next step I'd recommend iterating your config around different bridge scenarios to find what breaks it. +Then if reasonable try to exclude openstack from the equation as I shown above (or not if you think the fix needs to be in openstack). + +I hope this helped to get closer to the root casue, but I thought that a working example on the new Ocata stack might be the best start with. + +Note this was done on: +libvirt-daemon-system 3.6.0-1ubuntu4 +qemu-kvm 1:2.10+dfsg-0ubuntu1 + +Note - be careful if you mean upstream qemu/libvirt (as the bug was filed) or the packages in Ubuntu (I added tasks for these). +I try to spot both, but will be more on-track for the latter. + +I spent some time today trying to modify the ocata xml templates produced in /etc/libvirt/qemu/<INSTANCE-ID>.xml for each of the generated instances. Destroying & Undefining the existing instance, making some changes and redefining the xml, however it appears that nova regenerates these templates upon instance reset, thus removing any changes made to the xml template. Is there any way to disable this feature that does not require some serious modifications to the nova underpinnings? + +The problem is with virtio-mmio. + +https://bugzilla.redhat.com/show_bug.cgi?id=1422413 + +Instances launched with virtio-mmio on aarch64 will not get DHCP (will not have a nic) + +xml with libvirt 2.5.0 + + <interface type='bridge'> + <mac address='fa:16:3e:af:95:2e'/> + <source bridge='qbrb5abdeb0-a0'/> + <target dev='tapb5abdeb0-a0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='virtio-mmio'/> + +I have updated libvirt-daemon to 3.6.0 on a particular compute node - when an instance is booted now, the nic section of the virsh xml looks like this: + + <interface type='bridge'> + <mac address='fa:16:3e:10:0e:22'/> + <source bridge='qbr274809a0-dc'/> + <target dev='tap274809a0-dc'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + +The instance then gets a NIC and is able to get DHCP and complete cloud-init successfully. + + +So, +libvirt knew about some change and picks the right default if you do not specify it. +But if you (Openstack in this case) specify virtio-mmio as type, then it fails - is that correct? + +The patch in the referred RH-BZ is already in the qemu we have in Artful (and thereby Ocata). +So if that is supposed to be the issue there has to be a new one after that fix. + +Also as I've shown in c#17 (yes it is long sorry) - virtio-mmio works with the bridge that libvirt is usually creating - again my assumption is that it is somehow related to how this bridge is created (openvswitch in your case I assume). + +So is the real error "network fails when using virtio-mmio on openvswitch set up by openstack"? +I have no OVS around to quickly try something around that atm. + +Would it be reasonable to teach Openstack to not define virtio-mmio in this case? +Libvirt will make the right default (hopefully also when driven by Openstack which sets some force options), and just work then. + +Hi, +@admcleod as discussed on IRC I realized Ocata maps to Zesty so that is qemu 2.8. +Therefore the referred patch is released in Artful, but not in Zesty. + +I tagged up the bug tasks and provide a fix in [1] to test. + +[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2995 + +To further reinforce what Christian said, the Newton cloud-archive also uses virtio-mmio for its address type. (See my comment#15) + +Newton XML: + + <interface type='bridge'> + <mac address='fa:16:3e:8e:fc:48'/> + <source bridge='qbrb5d335fc-46'/> + <target dev='tapb5d335fc-46'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='virtio-mmio'/> + </interface> + +but we have proven this works with Newton. Is it fair to say this could be attributed to a change in OVS, between Newton and Ocata? + + + +This appears to be: https://bugzilla.redhat.com/show_bug.cgi?id=1422413 + +Yeah, the offending patch in RH-BZ 1422413 appeared in qemu 2.8. +So it would make sense to work with newtwon (2.6.1), and pike (2.10), but fail on Ocata (2.8). + +I checked the ppa, in general it seems to work for me, so I'm now waiting for your verification if that really addresses the issue you are facing. +If that would be the case I can pass it through regression tests and afterwards to SRU (which currently holds another update that has to clear before doing so) + +Since we wait for the zesty verification I'm setting the status to incomplete for now. + +Since the fix mentioned in the previous comments is already in upstream QEMU, I'm setting the upstream status to "Fix released". + +I've tested with the packages from the ppa: + +https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2995 + + +qemu: + Installed: 1:2.8+dfsg-3ubuntu2.7~ppa5cloud +qemu-system-arm: + Installed: 1:2.8+dfsg-3ubuntu2.7~ppa5cloud +qemu-system-aarch64: + Installed: 1:2.8+dfsg-3ubuntu2.7~ppa5cloud + + +Rebooted the instance and it aquired an IP address and booted. + + +more info, virsh dumpxml excerpt: + + <interface type='bridge'> + <mac address='fa:16:3e:4e:1f:8f'/> + <source bridge='qbrd542e755-45'/> + <target dev='tapd542e755-45'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='virtio-mmio'/> + +will test these and report back shortly. + +I've testing with the same packages listed in comment #28, Confirmed that this now works.. + +See attached log + +Ok, driving that into an SRU then - thanks for verifying. + +Regression tests on the ppa are good as well, we need to double check the auto-run on proposed then to ensure this doesn't behave differently on other arches. +I cleaned up the changelog and UCA backport noise and made a proper SRU for zesty. + +Note: there is currently another SRU in flight (already in verified state for 2 days), so acceptance from zesty-unapproved likely has to wait a bit until the former one clears completely + +I accepted this but Launchpad timed out when the SRU testing comment was being added. + +Thanks for the FYI Brian. +I see it in pending-SRUs as it should be. +I added the -needed tags to be "correct". + +@Andrew/Sean - could you test proposed and set verified then (assuming it works like the ppa did) + + +Odd - this really seems to hit everything, not only LP timeouts. +There are also dep8 regressions listed on systemd which make no sense in relation to the fix. +The test history on arm is borked since February [1], so I ask you to override and ignore that. +On s390x it at least works sometimes, but the log [2] doesn't look much better, but there at least it hits a different issue than before - I'm retriggering this for now - but likely ask to ignore that as well - but I'll take a look at the retry first. + + +[1]: http://autopkgtest.ubuntu.com/packages/s/systemd/zesty/armhf +[2]: http://autopkgtest.ubuntu.com/packages/s/systemd/zesty/s390x + +As assumed s390x passed now (so a flaky test), and as outlined before armhf we just have to give up. +Looking at the history an override might be the right thing to do. + +Other than that all looks good, waiting for the verify by Sean/Andrew now. + +Ok, Zesty actually had an override for the arm test (had to learn the placement of those for SRUs). +So only up to the verification now. + +Hello Sean, or anyone else affected, + +Accepted qemu into ocata-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. To enable the -proposed repository: + + sudo add-apt-repository cloud-archive:ocata-proposed + sudo apt-get update + +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-ocata-needed to verification-ocata-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-ocata-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Thanks Christian - I've now verified this. I took a stepwise approach: + +1) We originally observed this issue w/ the ocata cloud archive on xenial, so I redeployed that. I verified that I was still seeing the problem. I then created a PPA[*] w/ an arm64 build of QEMU from the ocata-staging PPA, which is a backport of the zesty-proposed package, and upgraded my nova-compute nodes to this version. I rebooted my test guests, and the problem was resolved. + +2) I then updated my sources.list to point to zesty (w/ proposed enabled), and upgraded qemu-system-arm. This way I could test the actual build in zesty-proposed, as opposed to my backport. This continued to work. + +3) Finally, I dist-upgraded this system from xenial to zesty - so that I'm actually testing the zesty build in a zesty environment, and rebooted. Still worked :) + +[*] https://launchpad.net/~dannf/+archive/ubuntu/lp1719196 + +This bug was fixed in the package qemu - 1:2.8+dfsg-3ubuntu2.7 + +--------------- +qemu (1:2.8+dfsg-3ubuntu2.7) zesty; urgency=medium + + * d/p/ubuntu/virtio-Fix-no-interrupt-when-not-creating-msi-contro.patch: + on Arm fix no interrupt when not creating msi controller. That fixes + broken networking if running with virtio-mmio only (LP: #1719196). + + -- Christian Ehrhardt <email address hidden> Wed, 18 Oct 2017 16:17:34 +0200 + +The verification of the Stable Release Update for qemu has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + + + +Regression testing has passed successfully. + +zesty-ocata-proposed with stable charms: + +====== +Totals +====== +Ran: 102 tests in 1897.0150 sec. + - Passed: 93 + - Skipped: 9 + - Expected Fail: 0 + - Unexpected Success: 0 + - Failed: 0 +Sum of execute time for each test: 1011.5607 sec. + +zesty-ocata-proposed with dev charms: + +====== +Totals +====== +Ran: 102 tests in 1933.5299 sec. + - Passed: 93 + - Skipped: 9 + - Expected Fail: 0 + - Unexpected Success: 0 + - Failed: 0 +Sum of execute time for each test: 963.0546 sec. + +xenial-ocata-proposed with stable charms: + +====== +Totals +====== +Ran: 102 tests in 1767.3787 sec. + - Passed: 93 + - Skipped: 9 + - Expected Fail: 0 + - Unexpected Success: 0 + - Failed: 0 +Sum of execute time for each test: 906.2188 sec. + +xenial-ocata-proposed with dev charms: + +====== +Totals +====== +Ran: 102 tests in 2051.1377 sec. + - Passed: 93 + - Skipped: 9 + - Expected Fail: 0 + - Unexpected Success: 0 + - Failed: 0 +Sum of execute time for each test: 998.9001 sec. + + diff --git a/results/classifier/118/graphic/1724590 b/results/classifier/118/graphic/1724590 new file mode 100644 index 000000000..04166fce8 --- /dev/null +++ b/results/classifier/118/graphic/1724590 @@ -0,0 +1,57 @@ +graphic: 0.870 +user-level: 0.844 +architecture: 0.832 +network: 0.809 +arm: 0.757 +device: 0.720 +performance: 0.691 +socket: 0.681 +ppc: 0.671 +kernel: 0.660 +semantic: 0.619 +register: 0.605 +hypervisor: 0.597 +mistranslation: 0.568 +PID: 0.565 +vnc: 0.562 +files: 0.558 +permissions: 0.528 +VMM: 0.518 +peripherals: 0.512 +risc-v: 0.497 +x86: 0.477 +TCG: 0.472 +assembly: 0.467 +debug: 0.454 +virtual: 0.440 +i386: 0.435 +KVM: 0.396 +boot: 0.362 + +Usermode networking hostfwd only listens on IPv4 + +When forwarding ports in usermode networking (-net user,hostfwd=), QEMU binds to IPv4 only. Therefore, connecting to the port over IPv6 results in 'connection refused'. + +I experienced this in QEMU 2.10.1, but it looks to still be present in the current master (861cd431c99e56ddb5953ca1da164a9c32b477ca), since slirp_hostfwd in net/slirp.c uses in_addr instead of in6_addr. + +Hello, + +This is indeed not implemented, patches welcome :) + +Samuel + +Hi Guys - I'm currently trying to use IPv6 with QEMU on ARM / AARCH64 Models (Sabre-Lite / Zync SOCs) and I see this problem. The system gets an IPv6 address from the QEMU in-built router which can be used to ping the default gateway (the dhcp router itself). All this is good but not really useful as I want to communicate with a TCP6 client on the host (Windows / Linux) machine running on port 8080. I've added the co-responding port mappings (like I do with IPv4) but I never receive packets from the host OS which is this issue. So I have the following questions, +- It seems that this issue is still open and on the wishlist. Is this correct ? If so, is there any ETA to when someone will take this up ? If none, may be I can look at this ;-).. I'm currently using QEMU 3.0 +- Assuming that its not working, what are the alternatives that I can use ? I understand that there is TAP-TUN Networking where the QEMU model can communicate with the hardware interface over a bridge.. This should work with IPv6.. Can you confirm ? + +This needs quick closure on my side and so quick comments will be appreciated.. + +Thanks, +Bilal + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1727737 b/results/classifier/118/graphic/1727737 new file mode 100644 index 000000000..1ac8e74fb --- /dev/null +++ b/results/classifier/118/graphic/1727737 @@ -0,0 +1,208 @@ +graphic: 0.907 +debug: 0.900 +mistranslation: 0.880 +semantic: 0.875 +permissions: 0.872 +architecture: 0.869 +assembly: 0.867 +peripherals: 0.867 +virtual: 0.863 +risc-v: 0.860 +PID: 0.857 +arm: 0.857 +ppc: 0.853 +kernel: 0.850 +user-level: 0.847 +performance: 0.842 +socket: 0.830 +device: 0.829 +files: 0.823 +vnc: 0.822 +KVM: 0.818 +boot: 0.811 +x86: 0.805 +network: 0.804 +register: 0.804 +hypervisor: 0.800 +VMM: 0.781 +TCG: 0.731 +i386: 0.664 + +qemu-arm stalls on a GCC sanitizer test since qemu-2.7 + +Hi, + +I have noticed that several GCC/sanitizer tests fail with timeout when executed under QEMU. + +After a bit of investigation, I have noticed that this worked with qemu-2.7, and started failing with qemu-2.8, and still fails with qemu-2.10.1 + +I'm attaching a tarball containing: +alloca_instruments_all_paddings.exe : the testcase, and the needed libs: +lib/librt.so.1 +lib/libdl.so.2 +lib/ld-linux-armhf.so.3 +lib/libasan.so.5 +lib/libc.so.6 +lib/libgcc_s.so.1 +lib/libpthread.so.0 +lib/libm.so.6 + +To reproduce the problem: +$ qemu-arm -cpu any -R 0 -L $PWD $PWD/alloca_instruments_all_paddings.exe +returns in less than a second with qemu-2.7, and never with qemu-2.8 + +Using -d in_asm suggests that the program "almost" completes and qemu seems to stall on: +0x40b6eb44: e08f4004 add r4, pc, r4 + + + +Hi. Your test case doesn't run for me: + +qemu-arm -cpu any -R 0 -L $PWD $PWD/alloca_instruments_all_paddings.exe +/tmp/bug1727737/alloca_instruments_all_paddings.exe: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory + +Did you forget to include one of the needed libs in the tarball? + + +Right, it worked for me because of the encoded rpath. +Here is the missing libstdc++.so.6 + + +Thanks. With that extra library, if I run with QEMU_STRACE=1 the following looks very suspicious: + +28865 getpid() = 28865 +28865 mmap2(NULL,2101248,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x43234000 +28865 mprotect(0x43234000,4096,PROT_NONE) = 0 +28865 rt_sigprocmask(SIG_BLOCK,0x40e077bc,0x40e0783c) = 0 +28865 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_UNTRACED,child_stack=0x43434ff8,parent_tidptr=0x00000000,tl +s=0x00000000,child_tidptr=0x00000000) = -1 errno=22 (Invalid argument) +28865 rt_sigprocmask(SIG_SETMASK,0x40e0783c,NULL) = 0 +28865 getpid() = 28865 +28865 sched_yield(1082131140,0,0,0,1084256812,1084256808) = 0 +28865 sched_yield(0,0,0,0,1084256812,1084256808) = 0 +28865 sched_yield(0,0,0,0,1084256812,1084256808) = 0 +28865 sched_yield(0,0,0,0,1084256812,1084256808) = 0 + + +It looks like the test case is (a) calling clone() with non-standard flags and (b) not checking whether it failed (presumably it then hangs forever waiting for the non-existent second thread to do something). + +This has started failing because we tightened up the handling of flags in our clone() syscall implementation: instead of blithely accepting any combination of flags but only giving you the behaviour that glibc pthread_create() gives, we now fail the clone() syscall if you ask for some behaviour we can't implement with pthread_create() or fork(). In this case you've asked for CLONE_VM|CLONE_FS|CLONE_FILES, which is very nearly a pthread thread but you also need CLONE_SIGHAND|CLONE_THREAD|CLONESYSVSEM. Also you ask for CLONE_UNTRACED, which we can't support. + +It's unfortunate that this tightening up of the checks means that some programs which ask for things we can't do but don't actually care about them will no longer run, but I think this is overall better than behaving wrongly for guest programs which do care, since we can't tell which is which. + + +I suspect this happens when the sanitizer library calls StopTheWorld() (in libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc in GCC sources). + +It does: + uptr tracer_pid = internal_clone( + TracerThread, tracer_stack.Bottom(), + CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_UNTRACED, + &tracer_thread_argument, nullptr /* parent_tidptr */, + nullptr /* newtls */, nullptr /* child_tidptr */); + +See: https://gcc.gnu.org/viewcvs/gcc/trunk/libsanitizer/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc?revision=253887&view=markup#l383 + +The recent merge with the upstream libsanitizer means that stoptheworld is now enabled on arm as well, leading to this call to internal_clone(). + +This matches the comment I received on the gcc-patches list: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02215.html +"LSan sets atexit handler that calls internal_clone function that's not supported in QEMU" + +I'm wondering why this works on aarch64? (I am also using QEMU for validations of aarch64 gcc). I mean the validations do not timeout. That being said, on aarch64 the test exits with 4 as return-code (like it did on arm with qemu-2.7) + +It also seems to me that the sanitizer lib is trying to handle the error (see if (internal_iserror(tracer_pid, &local_errno)) line 427). + +As a side note, doing +$ qemu-arm -E ASAN_OPTIONS=detect_leaks=0 blah +does not affect the execution, while +$ env ASAN_OPTIONS=detect_leaks=0 qemu-arm blah +does +(my question here being: why doesn't -E do what I want?) + + + +My bad: on aarch64 it does not "work", the test actually exits with a LeakSanitizer error message ("fatal error"). + +Using QEMU_STRACE=1 shows that clone() fails in the same way as for arm (which is expected), but apparently this error is handled better on aarch64, maybe because the internal_clone implementation is different. + + +I looked a bit more at the sanitizers source code, to understand the differences between arm and aarch64. And it turns out that on aarch64, we have: + +sanitizer_common/sanitizer_syscall_linux_aarch64.inc: +133 // Helper function used to avoid cobbler errno. +134 bool internal_iserror(uptr retval, int *rverrno) { +135 if (retval >= (uptr)-4095) { + +but on arm, in the GCC version, we use: + +sanitizer_common/sanitizer_syscall_generic.inc: +54 bool internal_iserror(uptr retval, int *rverrno) { +55 if (retval == (uptr)-1) { + +But recently (Nov 8th), the upstream sanitizer repo got a new file: + +sanitizer_common/sanitizer_syscall_linux_arm.inc +133 // Helper function used to avoid cobbler errno. +134 bool internal_iserror(uptr retval, int *rverrno) { +135 if (retval >= (uptr)-4095) { + +With that change, I now observe the same behaviour with qemu-aarch64 and qemu-arm. + + +I also looked at QEMU's code, and I am suprised that do_syscall() returns the value of errno rather than the return code from the syscall. So for instance, if clone() fails, do_syscall() returns get_errno(do_fork(...)) instead of -1. I thought the target code expects -1 in case of failure, but I'm not familiar with QEMU sources, so I'm probably missing something. + +Looking at QEMU's linux-user/syscall.c:do_fork(), I noticed several places with return -TARGET_EXXXX: should this be: +errno = TARGET_EXXX; +return -1; +instead? +But given than most (if not all) syscalls in do_syscall actually use 'ret = get_errno(xxxx)' I must be wrong :-) + + +Hmm, the do_fork() code is a bit inconsistent there. Generally in linux-user/ functions should either: +(1) return -1 with host errno set to a host errno; the caller then must use get_errno() to convert to the negative-target-errno that we need to return from do_syscall() +(2) return negative-target-errno; the caller then need do nothing + +In this case do_fork() is supposed to be using approach 2, but some code paths are using approach 1 and the callers are all using get_errno(). This hybrid approach works OK as long as none of the negative-target-errno values returned are -1 (which happens to be TARGET_EPERM for all architectures, and which we only use once in linux-user, in the sigaltstack handling). In an ideal world we'd clean this up to consistently use approach 2, but I don't think the code as it stands is actually buggy. + + +Thanks for the clarification. + +But how does the target get the actual syscall return code, if do_syscall() is supposed to return negative-target-errno? + +I mean, in general the target code will check if the syscall returned -1, and only then query errno? +But if QEMU's do_syscall returns -errno, and put this value in r0 (for arm) how is the target code supposed to work? + + +The kernel syscall ABI is "returns negative-errno". In the target code, if the libc ABI says "return -1 with errno set", it's the target libc code's job to move the return value into the TLS errno variable and return -1 from the library function. (Some target architectures have slightly weird ABIs like SPARC's "sets the carry flag on syscall failure" one; QEMU handles that kind of detail in the linux-user/main.c code which calls do_syscall().) + + +Thanks fixing my ignorance :-) + +So it really seems this is a feature, not a bug here. + +This was a bit off-topic, but I have a pending question in comment #5: +As a side note, doing +$ qemu-arm -E ASAN_OPTIONS=detect_leaks=0 blah +does not affect the execution, while +$ env ASAN_OPTIONS=detect_leaks=0 qemu-arm blah +does +(my question here being: why doesn't -E propagate ASA_OPTIONS to the target code?) + +No idea about the environment variable thing -- it seems to work for me. In a chroot: +# qemu-arm-static -E ASAN_OPTIONS=bar=baz /usr/bin/env +ASAN_OPTIONS=bar=baz +[... other things ...] + +shows that -E is being passed into the child process's environment as would be expected. + + +Ha! I think I found the problem.... the sanitizer reads /proc/self/environ, which is not where QEMU wrote the target environment... + +Thanks a lot for your support, I think you can close this report as: "it's a feature, not a bug". + + + +It would be nice if we got /proc/self/environ right, though... + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1728 b/results/classifier/118/graphic/1728 new file mode 100644 index 000000000..078908b6a --- /dev/null +++ b/results/classifier/118/graphic/1728 @@ -0,0 +1,48 @@ +graphic: 0.912 +x86: 0.909 +device: 0.889 +vnc: 0.818 +kernel: 0.786 +ppc: 0.747 +performance: 0.734 +network: 0.711 +mistranslation: 0.664 +virtual: 0.659 +PID: 0.651 +arm: 0.632 +architecture: 0.630 +semantic: 0.622 +risc-v: 0.589 +debug: 0.582 +boot: 0.564 +TCG: 0.529 +peripherals: 0.521 +hypervisor: 0.472 +VMM: 0.439 +register: 0.421 +socket: 0.420 +i386: 0.407 +permissions: 0.330 +KVM: 0.266 +user-level: 0.191 +assembly: 0.177 +files: 0.132 + +blockdev parameter does not accept dots in pool name in json config +Description of problem: +I'm trying to provision a VM using qemu 6.2.0 and pass the remote disk parameters like libvirt. When I start the VM, I get an error saying + + +``` +qemu-system-x86_64: -blockdev {driver:rbd,pool:cloud.disk.hiops,image:csi-vol-8577fffd-0f48-3344-b333-02000038163a,server:[{host:1.2.3.4,port:6789},{host:1.2.3.5,port:6789},{host:1.2.3.6,port:6789}],user:compute-staging,auth-client-required:[cephx,none],key-secret:ceph-secret,node-name:pv-MD7PBV3SRD21L08115JUJ94HMG,cache:{direct:false,no-flush:false},auto-read-only:true,discard:unmap}: JSON parse error, stray '.' +``` + + +I changed the ip address and some fields. + + +My question is should we avoid dots in pool name? I tried to look at the source code of json parser but in its doc, it did not mention a sequence of characters for escaping dots. +Steps to reproduce: +1. Provision a VM with the provided config +Additional information: +bl diff --git a/results/classifier/118/graphic/1731588 b/results/classifier/118/graphic/1731588 new file mode 100644 index 000000000..c8b5908fd --- /dev/null +++ b/results/classifier/118/graphic/1731588 @@ -0,0 +1,52 @@ +graphic: 0.912 +arm: 0.864 +device: 0.859 +peripherals: 0.782 +mistranslation: 0.758 +user-level: 0.741 +architecture: 0.736 +performance: 0.676 +semantic: 0.651 +kernel: 0.578 +ppc: 0.511 +network: 0.465 +permissions: 0.435 +register: 0.423 +PID: 0.400 +hypervisor: 0.398 +vnc: 0.387 +debug: 0.364 +socket: 0.349 +boot: 0.348 +x86: 0.336 +files: 0.298 +virtual: 0.291 +i386: 0.288 +TCG: 0.268 +risc-v: 0.259 +VMM: 0.237 +assembly: 0.180 +KVM: 0.067 + +qemu-system-arm black screen and keyboard not detected + +Hi guys, + +I try to emulate FreeRTOS with this guide : http://wiki.csie.ncku.edu.tw/embedded/Lab32 +But, the keys on my keyboard are not taken into account. + - Command line : qemu_stm32/arm-softmmu/qemu-system-arm -M stm32-p103 -monitor stdio -kernel build/main.bin -semihosting +If I try to add usb flag with : qemu_stm32/arm-softmmu/qemu-system-arm -M stm32-p103 -monitor stdio -kernel build/main.bin -usb -device usb-host,hostbus=1,hostaddr=1 -show-curso +I obtain this message "qemu-system-arm: -device usb-host,hostbus=1,hostaddr=1: 'usb-host' is not a valid device model name" + +My second option is try with the latest version of qemu with this command line : "qemu-system-arm -M lm3s6965evb -monitor stdio -kernel build/main.bin -semihosting" but I obtain a black screen. + +Could someone guide me on this problem ? + +"stm32-p103" is not a board model supported by upstream QEMU. Presumably you're using a fork of QEMU -- you should ask whoever is responsible for that fork about it. + + +For the second command line -- is the binary you're trying to run built for the stellaris board model you're trying to run it on? If it's the same binary you tried to use with the stm32 board model then I wouldn't expect it to work. You need to build a binary that targets the board model you run with. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1736 b/results/classifier/118/graphic/1736 new file mode 100644 index 000000000..5d3568f4c --- /dev/null +++ b/results/classifier/118/graphic/1736 @@ -0,0 +1,97 @@ +graphic: 0.926 +debug: 0.919 +peripherals: 0.917 +permissions: 0.907 +semantic: 0.900 +files: 0.893 +TCG: 0.863 +register: 0.860 +arm: 0.858 +performance: 0.854 +virtual: 0.854 +device: 0.852 +assembly: 0.852 +PID: 0.844 +architecture: 0.834 +mistranslation: 0.831 +ppc: 0.811 +hypervisor: 0.811 +socket: 0.790 +boot: 0.787 +vnc: 0.780 +VMM: 0.772 +KVM: 0.731 +network: 0.729 +risc-v: 0.689 +kernel: 0.686 +user-level: 0.685 +i386: 0.676 +x86: 0.627 + +Invalid guest addr in debug output +Description of problem: +When using QEMU 7.1.0 the log file for the first translation block (not starting at 0) looks like this: +(Note the `guest addr 0x00010000`) +``` +IN: +0x00010000: e1a00000 mov r0, r0 +0x00010004: e1a00000 mov r0, r0 +0x00010008: e1a00000 mov r0, r0 +0x0001000c: e1a00000 mov r0, r0 +0x00010010: e1a00000 mov r0, r0 +0x00010014: e1a00000 mov r0, r0 +0x00010018: e1a00000 mov r0, r0 +0x0001001c: e1a00000 mov r0, r0 +0x00010020: ea000005 b #0x1003c + +OUT: [size=47] + -- guest addr 0x00010000 + tb prologue +0x7f95a8000300: 8b 5d f0 movl -0x10(%rbp), %ebx +0x7f95a8000303: 85 db testl %ebx, %ebx +0x7f95a8000305: 0f 8c 18 00 00 00 jl 0x7f95a8000323 + -- guest addr 0x00010020 +0x7f95a800030b: e9 00 00 00 00 jmp 0x7f95a8000310 +0x7f95a8000310: c7 45 3c 3c 00 01 00 movl $0x1003c, 0x3c(%rbp) +0x7f95a8000317: 48 8d 05 22 ff ff ff leaq -0xde(%rip), %rax +0x7f95a800031e: e9 f5 fc ff ff jmp 0x7f95a8000018 +0x7f95a8000323: 48 8d 05 19 ff ff ff leaq -0xe7(%rip), %rax +0x7f95a800032a: e9 e9 fc ff ff jmp 0x7f95a8000018 +``` + +For QEMU 7.2.0 and higher: +(Note the `guest addr` is only the page offset.) +``` +Trace 0: 0x7fe434000100 [00000400/00000000/00000020/ff200000] +---------------- +IN: +0x00010000: e1a00000 mov r0, r0 +0x00010004: e1a00000 mov r0, r0 +0x00010008: e1a00000 mov r0, r0 +0x0001000c: e1a00000 mov r0, r0 +0x00010010: e1a00000 mov r0, r0 +0x00010014: e1a00000 mov r0, r0 +0x00010018: e1a00000 mov r0, r0 +0x0001001c: e1a00000 mov r0, r0 +0x00010020: ea000005 b #0x1003c + +OUT: [size=52] + -- guest addr 0x00000000 + tb prologue +0x7fe434000340: 8b 5d f0 movl -0x10(%rbp), %ebx +0x7fe434000343: 85 db testl %ebx, %ebx +0x7fe434000345: 0f 8c 1d 00 00 00 jl 0x7fe434000368 + -- guest addr 0x00000020 +0x7fe43400034b: 8b 5d 3c movl 0x3c(%rbp), %ebx +0x7fe43400034e: 83 c3 3c addl $0x3c, %ebx +0x7fe434000351: 89 5d 3c movl %ebx, 0x3c(%rbp) +0x7fe434000354: 66 66 90 nop +0x7fe434000357: e9 00 00 00 00 jmp 0x7fe43400035c +0x7fe43400035c: 48 8d 05 1d ff ff ff leaq -0xe3(%rip), %rax +0x7fe434000363: e9 b0 fc ff ff jmp 0x7fe434000018 +0x7fe434000368: 48 8d 05 14 ff ff ff leaq -0xec(%rip), %rax +0x7fe43400036f: e9 a4 fc ff ff jmp 0x7fe434000018 +``` +Steps to reproduce: +1. Run the provided command line for any kernel / system image. (likely other architectures are affected as well) +2. Look into the debug log. +Additional information: +While looking if this was already reported I found #1528 and #1697 which could potentially caused by this. It might as well be just an oversight in the debug output. diff --git a/results/classifier/118/graphic/1738202 b/results/classifier/118/graphic/1738202 new file mode 100644 index 000000000..3277b0443 --- /dev/null +++ b/results/classifier/118/graphic/1738202 @@ -0,0 +1,80 @@ +graphic: 0.882 +peripherals: 0.842 +architecture: 0.794 +performance: 0.780 +files: 0.770 +semantic: 0.759 +register: 0.756 +socket: 0.755 +permissions: 0.739 +debug: 0.739 +device: 0.705 +ppc: 0.699 +network: 0.693 +PID: 0.677 +hypervisor: 0.673 +arm: 0.651 +mistranslation: 0.644 +assembly: 0.640 +vnc: 0.623 +boot: 0.607 +virtual: 0.575 +TCG: 0.569 +user-level: 0.568 +risc-v: 0.554 +kernel: 0.548 +x86: 0.534 +VMM: 0.483 +KVM: 0.449 +i386: 0.332 + +qemu 2.11 segfaults on elf file that worked with qemu2.7 + +running on cygwin in Windows 7 + +QEMU 2.10.93 segfaults: +$ /opt/qemu2.11/qemu-system-arm -M integratorcp -cpu cortex-m4 -semihosting -nographic -monitor null -serial null -no-reboot -kernel MFWso_Cycle_f1uP2_CUNIT_0.elf +Segmentation fault + +where QEMU 2.7.0 worked: +$ /opt/qemu2.7/qemu-system-arm -M integratorcp -cpu cortex-m4 -semihosting -nographic -monitor null -serial null -no-reboot -kernel MFWso_Cycle_f1uP2_CUNIT_0.elf +------------ CUnit_MFWso_Cycle_f1 ------------ + + + CUnit - A Unit testing framework for C - Version 2.1-0 + http://cunit.sourceforge.net/ + + +Suite: Suite_MFWso_Cycle_f1 + Test: MFWso_Cycle_f1() ... passed + Test: MFWso_GetPhysicalStateData() ... passed + Test: MFWso_GetOutputData() ... passed + Test: MFWso_GetSafeChannelOK() ... passed + +--Run Summary: Type Total Ran Passed Failed + suites 1 1 n/a 0 + tests 4 4 4 0 + asserts 54 54 54 0 + +---------------------------------------- + +Omitting the -cpu parameter results (for both versions) to hang of qemu (no output, no end, full cpu load). + + + +Your command line is badly broken: "-M integratorcp" requests a model of an integratorcp board, but "-cpu cortex-m4" tries to put an M-profile CPU in it, which is not something that board can support. In particular the resulting system model will have no NVIC in it. This only worked by accident in previous versions of QEMU. + +Ideally we should have better cpu-model compatibility checking in the board models, in which case we could print a message saying "CPU type cortex-m4 is not compatible with the integratorcp board" rather than crashing. + +If you omit -cpu you'll get the default CPU type for the board, which is an arm926. That's a sensible board+cpu combination but presumably your guest code is not built to run on that hardware, which will be why it just falls over. ("QEMU prints no output" often means "guest code has crashed or gone into an infinite loop", rather than a QEMU bug.) + +If your code needs to run on an M-profile CPU then you'll need to pick one of the M-profile board models. As of 2.11 those are lm3s6965evb, lm3s811evb, mps2-an385, mps2-an511, netduino2. + + +Thanks Peter for this information! + +I guess our code was tweaked to run with this options a long time ago - so I will have to do some investigations to get it working with a valid NVIC... + +As of writing I remember having a similar issue some time ago (which I now found to have resulted in Bug 1636126). +Sorry for not remembering this before! + diff --git a/results/classifier/118/graphic/1739 b/results/classifier/118/graphic/1739 new file mode 100644 index 000000000..c13689ba6 --- /dev/null +++ b/results/classifier/118/graphic/1739 @@ -0,0 +1,66 @@ +graphic: 0.957 +files: 0.951 +user-level: 0.931 +ppc: 0.910 +PID: 0.895 +performance: 0.891 +architecture: 0.874 +device: 0.859 +socket: 0.858 +debug: 0.831 +register: 0.818 +permissions: 0.800 +network: 0.794 +peripherals: 0.790 +hypervisor: 0.774 +semantic: 0.758 +VMM: 0.741 +vnc: 0.727 +arm: 0.697 +assembly: 0.694 +kernel: 0.675 +mistranslation: 0.628 +boot: 0.625 +TCG: 0.621 +x86: 0.606 +KVM: 0.577 +i386: 0.571 +virtual: 0.537 +risc-v: 0.465 + +Build process is broken in /audio/dbusaudio.c:36: pixman.h cannot be found +Description of problem: +Hello. + +I try to build qemu using commit aa1048e33c. But build process stop in /audio/dbusaudio.c with this error log: + +``` +[979/9916] Generating audio-dbus.modin...d (wrapped by meson to capture output) +FAILED: audio-dbus.modinfo +/home/fred/qemu-git/src/qemu/build-full/pyvenv/bin/meson --internal exe --capture audio-dbus.modinfo -- /home/fred/qemu-git/src/qemu/build-full/pyvenv/bin/python3 /home/fred/qemu-git/src/qemu/scripts/modinfo-collect.py ../audio/dbusaudio.c +--- stderr --- +In file included from /home/fred/qemu-git/src/qemu/include/ui/console.h:4, + from /home/fred/qemu-git/src/qemu/ui/dbus.h:31, + from ../audio/dbusaudio.c:36: +/home/fred/qemu-git/src/qemu/include/ui/qemu-pixman.h:12:10: fatal error: pixman.h: No such file or directory + 12 | #include <pixman.h> + | ^~~~~~~~~~ +compilation terminated. +``` + +Of course I have pixman.h which could be find in pixman package: + +``` +pacman -Ql pixman | grep pixman.h +pixman /usr/include/pixman-1/pixman.h +``` + +Used configuration: ```--prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror``` + +The last time I got a buildable qemu was with commit 79dbd910c9, 3 days ago. +Steps to reproduce: +1. Grab latest commit +2. Use this configure line: ```--prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror``` +3. make and wait +Additional information: + diff --git a/results/classifier/118/graphic/1743441 b/results/classifier/118/graphic/1743441 new file mode 100644 index 000000000..f8b9c8c9e --- /dev/null +++ b/results/classifier/118/graphic/1743441 @@ -0,0 +1,42 @@ +graphic: 0.922 +i386: 0.880 +mistranslation: 0.875 +device: 0.811 +boot: 0.808 +semantic: 0.674 +performance: 0.654 +architecture: 0.628 +x86: 0.579 +vnc: 0.533 +hypervisor: 0.525 +user-level: 0.504 +socket: 0.419 +network: 0.415 +kernel: 0.371 +permissions: 0.363 +files: 0.348 +arm: 0.303 +register: 0.273 +debug: 0.273 +ppc: 0.206 +virtual: 0.187 +PID: 0.185 +peripherals: 0.176 +assembly: 0.122 +risc-v: 0.115 +VMM: 0.080 +TCG: 0.079 +KVM: 0.006 + +OS/2 Warp 4.52 OS2LVM failure + +When I try to boot OS/2 Warp 4.51 (Merlin), 4.52 (Aurora) or eCS 1.2.5, etc. I always get an exception in OS2LVM (TRAP 000E). You can reproduce the bug using this disk image: https://drive.google.com/open?id=1zzjs9hTS0TK-Xb5hnon8SQ-2C1EmlYfy + + + +Is this a regression on previous behaviour or has never worked? What is the command line you used to launch QEMU? What version have you tested on? + +As far as I know it has never worked. I have checked it on version 2.11 and attached a link to my disk image. I used qemu-system-i386w -cpu pentium3 -m 128 -hda c.img -boot c + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1748434 b/results/classifier/118/graphic/1748434 new file mode 100644 index 000000000..5dbb46c8f --- /dev/null +++ b/results/classifier/118/graphic/1748434 @@ -0,0 +1,102 @@ +graphic: 0.933 +performance: 0.917 +semantic: 0.914 +virtual: 0.908 +debug: 0.906 +peripherals: 0.889 +KVM: 0.885 +assembly: 0.885 +permissions: 0.884 +architecture: 0.872 +hypervisor: 0.871 +risc-v: 0.863 +TCG: 0.861 +arm: 0.856 +vnc: 0.855 +device: 0.850 +ppc: 0.839 +PID: 0.831 +kernel: 0.821 +VMM: 0.808 +boot: 0.807 +register: 0.799 +user-level: 0.792 +mistranslation: 0.789 +files: 0.784 +network: 0.770 +socket: 0.766 +x86: 0.746 +i386: 0.662 + +Possibly wrong GICv3 behavior when secure enabled + +I an tried arm-aarch64 interrupt routing to EL3, by SCR_EL3.FIQ=1. First I am started QEMU with secure=on and GICv3 support. +I programmed secure and non-secure timers and set-up appropriate interrupts.Secure timer to be GRP1_Secure and non-secure timer to be GRP1_NonSecure. ICC_PMR = 0xff. Then I switched CPU to EL1. +With that setup no interrupt was delivered to PE. GIC interface showed that non secure IRQ is pending. ICC_PMR read at EL1 returns 0 (shall return value ((PMR_(el3) << 1) & 0xff) according to GIC specification. +Than I tried to increase interrupt priority mask - so I set ICC_PMR = 0x7f (at EL3). Then I read at EL1 ICC_PMR=0xfe - (is shall be 0). With this setup IRQ of secure timer was taken at EL3, non secure timer didn't rise IRQ (as it is masked by PMR). +I dig to qemu code and see wrong condition in file arm_gicv3_cpuif.c in function icc_pmr_read(). This behavior is opposite of ARM specification. + +see possible solution, in #if 0 is original code in #else see possible fix + +static uint64_t icc_pmr_read(CPUARMState *env, const ARMCPRegInfo *ri) +.... +#if 0 // KIURCHER: bug - shall be opposite; see ARM specification + if (value & 0x80) { + /* Secure priorities not visible to NS */ + value = 0; + } else if (value != 0xff) { + value = (value << 1) & 0xff; + } +#else + + if (value & 0x80) { + value = (value << 1) & 0xff; + } else { + value = 0; + } +#endif +.... + + +static void icc_pmr_write(CPUARMState *env, const ARMCPRegInfo *ri, + uint64_t value) +.... +#if 0 //KIURCHER: bug + if (arm_feature(env, ARM_FEATURE_EL3) && !arm_is_secure(env) && + (env->cp15.scr_el3 & SCR_FIQ)) { + /* NS access and Group 0 is inaccessible to NS: return the + * NS view of the current priority + */ + if (!(cs->icc_pmr_el1 & 0x80)) { + /* Current PMR in the secure range, don't allow NS to change it */ + return; + } + value = (value >> 1) & 0x80; + } +#else + if (arm_feature(env, ARM_FEATURE_EL3) && !arm_is_secure(env) && + (env->cp15.scr_el3 & SCR_FIQ)) { + /* NS access and Group 0 is inaccessible to NS: return the + * NS view of the current priority + */ + if (!(cs->icc_pmr_el1 & 0x80)) { + /* Current PMR in the secure range, don't allow NS to change it */ + return; + } + value = (value >> 1) | 0x80; + } +#endif + + + + +Whoops, yes, we have the wrong condition for ICC_PMR non-secure reads and writes. We also have the same bug in ICC_RPR reads. I'll put together a patch and send it to the mailing list. + + +Patch which should fix this: +https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg04537.html + + +Now fixed in master in commit a2e2d7fc46fd8be, so will be in 2.12.0. + + diff --git a/results/classifier/118/graphic/1749016 b/results/classifier/118/graphic/1749016 new file mode 100644 index 000000000..9f5a77917 --- /dev/null +++ b/results/classifier/118/graphic/1749016 @@ -0,0 +1,185 @@ +graphic: 0.904 +permissions: 0.896 +register: 0.891 +assembly: 0.890 +socket: 0.885 +virtual: 0.883 +PID: 0.880 +debug: 0.878 +kernel: 0.875 +semantic: 0.873 +device: 0.872 +architecture: 0.871 +arm: 0.869 +performance: 0.867 +mistranslation: 0.852 +user-level: 0.840 +boot: 0.839 +risc-v: 0.835 +hypervisor: 0.833 +network: 0.828 +vnc: 0.822 +VMM: 0.810 +KVM: 0.803 +files: 0.798 +peripherals: 0.796 +ppc: 0.783 +TCG: 0.778 +x86: 0.776 +i386: 0.698 + +VHDX BAT and Metadata Region Header Required Bit Not Set + +When converting a VMDK to VHDX the resulting VHDX's Region table has a small error. According to the VHDX specification the BAT and Metadata entries for the region header required bit should be set to 1. In a VHDX created by qemu-img, this bit is not set. + +See Table 4: Known Region Properties of the VHDX specification. + +The structure format is as following from Structure 4: Region Table Entry: + +struct VHDX_REGION_TABLE_ENTRY { +GUID Guid; +UINT64 FileOffset; +UINT32 Length; +UINT32 Required:1; +UINT32 Reserved:31; +} + +The Required bit for VHDX specified BAT and Metadata Regions Required bit in the entry is not set as required in the current specification. + +VHDX Region Table in a valid VHDX + +Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F +0x00030000 72 65 67 69 AE 8C 6B C6 02 00 00 00 00 00 00 00 +0x00030010 66 77 C2 2D 23 F6 00 42 9D 64 11 5E 9B FD 4A 08 +0x00030020 00 00 30 00 00 00 00 00 00 00 10 00 01 00 00 00 +0x00030030 06 A2 7C 8B 90 47 9A 4B B8 FE 57 5F 05 0F 88 6E +0x00030040 00 00 20 00 00 00 00 00 00 00 10 00 01 00 00 00 + +VHDX Region Table in a VHDX converted by qemu-img from VMDK + +Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F +0x00030000 72 65 67 69 AE 8C 6B C6 02 00 00 00 00 00 00 00 +0x00030010 66 77 C2 2D 23 F6 00 42 9D 64 11 5E 9B FD 4A 08 +0x00030020 00 00 30 00 00 00 00 00 00 00 10 00 00 00 00 00 +0x00030030 06 A2 7C 8B 90 47 9A 4B B8 FE 57 5F 05 0F 88 6E +0x00030040 00 00 20 00 00 00 00 00 00 00 10 00 00 00 00 00 + +The fist bit at 0x0003002A and 0x0003004A should be set to 1. + +On Mon, Feb 12, 2018 at 09:44:09PM -0000, Michael Fruchtman wrote: +> Public bug reported: +> +> When converting a VMDK to VHDX the resulting VHDX's Region table has a +> small error. According to the VHDX specification the BAT and Metadata +> entries for the region header required bit should be set to 1. In a +> VHDX created by qemu-img, this bit is not set. + +CCing Jeff Cody, VHDX maintainer. + +> +> See Table 4: Known Region Properties of the VHDX specification. +> +> The structure format is as following from Structure 4: Region Table +> Entry: +> +> struct VHDX_REGION_TABLE_ENTRY { +> GUID Guid; +> UINT64 FileOffset; +> UINT32 Length; +> UINT32 Required:1; +> UINT32 Reserved:31; +> } +> +> The Required bit for VHDX specified BAT and Metadata Regions Required +> bit in the entry is not set as required in the current specification. +> +> VHDX Region Table in a valid VHDX +> +> Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F +> 0x00030000 72 65 67 69 AE 8C 6B C6 02 00 00 00 00 00 00 00 +> 0x00030010 66 77 C2 2D 23 F6 00 42 9D 64 11 5E 9B FD 4A 08 +> 0x00030020 00 00 30 00 00 00 00 00 00 00 10 00 01 00 00 00 +> 0x00030030 06 A2 7C 8B 90 47 9A 4B B8 FE 57 5F 05 0F 88 6E +> 0x00030040 00 00 20 00 00 00 00 00 00 00 10 00 01 00 00 00 +> +> VHDX Region Table in a VHDX converted by qemu-img from VMDK +> +> Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F +> 0x00030000 72 65 67 69 AE 8C 6B C6 02 00 00 00 00 00 00 00 +> 0x00030010 66 77 C2 2D 23 F6 00 42 9D 64 11 5E 9B FD 4A 08 +> 0x00030020 00 00 30 00 00 00 00 00 00 00 10 00 00 00 00 00 +> 0x00030030 06 A2 7C 8B 90 47 9A 4B B8 FE 57 5F 05 0F 88 6E +> 0x00030040 00 00 20 00 00 00 00 00 00 00 10 00 00 00 00 00 +> +> The fist bit at 0x0003002A and 0x0003004A should be set to 1. +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> +> ** Tags: qemu-img vhdx +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1749016 +> +> Title: +> VHDX BAT and Metadata Region Header Required Bit Not Set +> +> Status in QEMU: +> New +> +> Bug description: +> When converting a VMDK to VHDX the resulting VHDX's Region table has a +> small error. According to the VHDX specification the BAT and Metadata +> entries for the region header required bit should be set to 1. In a +> VHDX created by qemu-img, this bit is not set. +> +> See Table 4: Known Region Properties of the VHDX specification. +> +> The structure format is as following from Structure 4: Region Table +> Entry: +> +> struct VHDX_REGION_TABLE_ENTRY { +> GUID Guid; +> UINT64 FileOffset; +> UINT32 Length; +> UINT32 Required:1; +> UINT32 Reserved:31; +> } +> +> The Required bit for VHDX specified BAT and Metadata Regions Required +> bit in the entry is not set as required in the current specification. +> +> VHDX Region Table in a valid VHDX +> +> Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F +> 0x00030000 72 65 67 69 AE 8C 6B C6 02 00 00 00 00 00 00 00 +> 0x00030010 66 77 C2 2D 23 F6 00 42 9D 64 11 5E 9B FD 4A 08 +> 0x00030020 00 00 30 00 00 00 00 00 00 00 10 00 01 00 00 00 +> 0x00030030 06 A2 7C 8B 90 47 9A 4B B8 FE 57 5F 05 0F 88 6E +> 0x00030040 00 00 20 00 00 00 00 00 00 00 10 00 01 00 00 00 +> +> VHDX Region Table in a VHDX converted by qemu-img from VMDK +> +> Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F +> 0x00030000 72 65 67 69 AE 8C 6B C6 02 00 00 00 00 00 00 00 +> 0x00030010 66 77 C2 2D 23 F6 00 42 9D 64 11 5E 9B FD 4A 08 +> 0x00030020 00 00 30 00 00 00 00 00 00 00 10 00 00 00 00 00 +> 0x00030030 06 A2 7C 8B 90 47 9A 4B B8 FE 57 5F 05 0F 88 6E +> 0x00030040 00 00 20 00 00 00 00 00 00 00 10 00 00 00 00 00 +> +> The fist bit at 0x0003002A and 0x0003004A should be set to 1. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1749016/+subscriptions +> + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1755 b/results/classifier/118/graphic/1755 new file mode 100644 index 000000000..57c00ac69 --- /dev/null +++ b/results/classifier/118/graphic/1755 @@ -0,0 +1,50 @@ +graphic: 0.827 +architecture: 0.804 +user-level: 0.795 +performance: 0.781 +device: 0.764 +x86: 0.742 +arm: 0.719 +files: 0.709 +permissions: 0.705 +network: 0.638 +PID: 0.627 +socket: 0.614 +peripherals: 0.536 +semantic: 0.530 +ppc: 0.523 +register: 0.521 +mistranslation: 0.497 +VMM: 0.479 +vnc: 0.474 +TCG: 0.466 +hypervisor: 0.424 +boot: 0.394 +kernel: 0.394 +assembly: 0.367 +risc-v: 0.341 +virtual: 0.305 +i386: 0.294 +KVM: 0.293 +debug: 0.179 + +qemu-arm fails to execute a cortex-M binary (page_set_flags: Assertion 'last <= GUEST_ADDR_MAX' failed.) +Description of problem: +I've noticed that qemu-arm (so linux-user mode) fails to execute a binary targeting cortex-M. This used to work until commit +"Make the commpage executable". +Steps to reproduce: +1. Compile a simple hello.c for arm-eabi. If you don't have such a toolchain, you can download one from https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads For instance https://developer.arm.com/-/media/Files/downloads/gnu/12.2.rel1/binrel/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi.tar.xz (for an x86_64 linux host) + +2.# compile for cortex-m3: + +3. arm-none-eabi-gcc hello.c -o hello.exe.m3 -mcpu=cortex-m3 -specs=rdimon.specs + +4.qemu-arm -cpu cortex-m3 hello.exe.m3 +.....user-exec.c:492: page_set_flags: Assertion 'last <= GUEST_ADDR_MAX' failed. + +5. # compile for cortex-a9: + +6. arm-none-eabi-gcc hello.c -o hello.exe.a9 -mcpu=cortex-a9 -specs=rdimon.specs + +7. qemu-arm -cpu cortex-a9 hello.exe.a9 +Hello diff --git a/results/classifier/118/graphic/1757363 b/results/classifier/118/graphic/1757363 new file mode 100644 index 000000000..4d7b9e103 --- /dev/null +++ b/results/classifier/118/graphic/1757363 @@ -0,0 +1,84 @@ +graphic: 0.958 +architecture: 0.873 +x86: 0.855 +performance: 0.819 +mistranslation: 0.808 +kernel: 0.807 +device: 0.779 +ppc: 0.769 +debug: 0.748 +user-level: 0.737 +network: 0.653 +permissions: 0.642 +semantic: 0.638 +peripherals: 0.620 +TCG: 0.612 +PID: 0.589 +files: 0.528 +register: 0.506 +boot: 0.490 +hypervisor: 0.487 +vnc: 0.434 +socket: 0.412 +risc-v: 0.378 +virtual: 0.373 +KVM: 0.371 +VMM: 0.335 +arm: 0.308 +i386: 0.264 +assembly: 0.263 + +infinite loop due to improper deal with "eret" on mips32 + +1.qemu 2.9.1 release on the official web build with tcg +2.cmd: qemu-system-mips -kernel kernelfile +3. host: ubuntu 16.04.1 with linux kernel 4.6.2 x86_64 + guest: mips bigendian 32bit (tplink firmware) + + +detail: + +static inline void exception_return(CPUMIPSState *env) +{ + debug_pre_eret(env); + if (env->CP0_Status & (1 << CP0St_ERL)) { + set_pc(env, env->CP0_ErrorEPC); + env->CP0_Status &= ~(1 << CP0St_ERL); + } else { + set_pc(env, env->CP0_EPC); + env->CP0_Status &= ~(1 << CP0St_EXL);====================> ISSUE???? + } + compute_hflags(env); + debug_post_eret(env); +} + +void helper_eret(CPUMIPSState *env) +{ + exception_return(env); + env->lladdr = 1; +} + + +In the Issue Line, there is no check CP0_Status whether int is disabled (should not enter int routine), +that result in the cpu can not jump out the int routine. + +What model/cpu is your router? + +Which MIPS guest CPU are you using? Are you sure it matches the CPU of your router? + +Is your tplink firmware publicly available? (to reproduce your problem). + +My guess is your router CPU doesn't match the ISA (likely your CPU has extensions to the 24Kf ISA). + +[Expired for QEMU because there has been no activity for 60 days.] + +This seems to affect me too; I have a loop on interrupt handler after the first interrupt called. + +The version of qemu is latest 3.1 from upstream, so this is not Ubuntu issue. + +However, have you done with it? Just commenting out + +env->CP0_Status &= ~(1 << CP0St_EXL); + +does not help. + diff --git a/results/classifier/118/graphic/1758 b/results/classifier/118/graphic/1758 new file mode 100644 index 000000000..f70d1b9e4 --- /dev/null +++ b/results/classifier/118/graphic/1758 @@ -0,0 +1,42 @@ +graphic: 0.884 +device: 0.862 +files: 0.803 +socket: 0.788 +semantic: 0.646 +network: 0.576 +mistranslation: 0.495 +PID: 0.426 +boot: 0.397 +arm: 0.397 +debug: 0.375 +user-level: 0.364 +performance: 0.342 +register: 0.320 +architecture: 0.310 +peripherals: 0.223 +vnc: 0.193 +risc-v: 0.189 +TCG: 0.163 +permissions: 0.151 +virtual: 0.115 +kernel: 0.112 +ppc: 0.110 +VMM: 0.065 +assembly: 0.052 +hypervisor: 0.037 +x86: 0.011 +i386: 0.009 +KVM: 0.006 + +libssh missing on macOS/m1 +Description of problem: +I did a "git pull" in my source for qemu. Now when I do "make" I get: +../block/ssh.c:27:10: fatal error: 'libssh/libssh.h' file not found + +Am I supposed to install libssh separately? I were able to compile qemu about a month ago or so. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/118/graphic/1766841 b/results/classifier/118/graphic/1766841 new file mode 100644 index 000000000..f7850b2e7 --- /dev/null +++ b/results/classifier/118/graphic/1766841 @@ -0,0 +1,111 @@ +graphic: 0.823 +semantic: 0.788 +user-level: 0.773 +hypervisor: 0.770 +virtual: 0.768 +assembly: 0.768 +permissions: 0.765 +register: 0.759 +KVM: 0.754 +peripherals: 0.750 +performance: 0.745 +architecture: 0.743 +debug: 0.731 +TCG: 0.721 +vnc: 0.714 +device: 0.713 +VMM: 0.713 +risc-v: 0.701 +arm: 0.694 +socket: 0.692 +network: 0.666 +mistranslation: 0.663 +ppc: 0.651 +PID: 0.638 +x86: 0.630 +kernel: 0.608 +boot: 0.603 +files: 0.548 +i386: 0.390 + +QEMU 2.12 Running Problem in Windows 7 Installation + +QEMU Version: 2.12 (Binary installer qemu-w64-setup-20180424.exe from Stefan Weil's website so I am not sure I should report it to Weil by email or by this bug report system.) +Host System: Windows 7 64bit +Guest System: 9front 6350 (Codename“CONTENTS, MAINTAINED, STABLE”, Release 2018/02/02) + +QEMU Command: +qemu-system-x86_64 -usb -device usb-mouse -hda plan9.qcow2.img -cdrom 9front-6350.iso -boot d + +QEMU warning: +(qemu-system-x86_64.exe:8844): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file 'D:\qemu\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache': No such file or directory + +This likely means that your installation is broken. +Try running the command + gdk-pixbuf-query-loaders > D:\qemu\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache +to make things work again for the time being. + +(qemu-system-x86_64.exe:8844): Gtk-WARNING **: Could not find the icon 'window-minimize-symbolic-ltr'. The 'hicolor' theme was not found either, perhaps you need to install it. +You can get a copy from: + http://icon-theme.freedesktop.org/releases + +On Wed, Apr 25, 2018 at 10:23:07AM -0000, Justin wrote: +> Public bug reported: +> +> QEMU Version: 2.12 (Binary installer qemu-w64-setup-20180424.exe from Stefan Weil's website so I am not sure I should report it to Weil by email or by this bug report system.) +> Host System: Windows 7 64bit +> Guest System: 9front 6350 (Codename“CONTENTS, MAINTAINED, STABLE”, Release 2018/02/02) +> +> QEMU Command: +> qemu-system-x86_64 -usb -device usb-mouse -hda plan9.qcow2.img -cdrom 9front-6350.iso -boot d +> +> QEMU warning: +> (qemu-system-x86_64.exe:8844): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file 'D:\qemu\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache': No such file or directory +> +> This likely means that your installation is broken. +> Try running the command +> gdk-pixbuf-query-loaders > D:\qemu\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache +> to make things work again for the time being. +> +> (qemu-system-x86_64.exe:8844): Gtk-WARNING **: Could not find the icon 'window-minimize-symbolic-ltr'. The 'hicolor' theme was not found either, perhaps you need to install it. +> You can get a copy from: +> http://icon-theme.freedesktop.org/releases +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> +> ** Tags: installation windows +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1766841 + +CCing Stefan Weil in case he hasn't seen this yet. + +Stefan + + +Both messages are warnings – QEMU will work nevertheless. + +The first warning can be fixed as the message says (that needs an additional installation of Cygwin for gdk-pixbuf-query-loaders). It is also suppressed if there is an empty file loaders.cache. Newer installers (for example those from today) will create such an empty file automatically. + +I don't get the second warning. + +Rechecked in my site, the new installer (20180430) had solved the 1st problem, but it leads to another problem: When uninstall QEMU, the loaders.cache file cannot be deleted automatically. + +For 2nd warning, I checked it again, when I choosed fully installing, the icons are displayed correctly; But when I just installed the x64 & x64w simulator, the icons are lost and the 2nd warning message shown. It seems some dependent file is not installed when performing a selected installation. + +I discovered that the following directory is not installed when the "Desktop icons" component is unchecked during installation: + + qemu\share\icons + +Such directory contains two subdirectories: "Adwaita" and "hicolor". When they're present, the bug does not occur. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1767200 b/results/classifier/118/graphic/1767200 new file mode 100644 index 000000000..69c605a30 --- /dev/null +++ b/results/classifier/118/graphic/1767200 @@ -0,0 +1,51 @@ +graphic: 0.822 +kernel: 0.753 +device: 0.659 +architecture: 0.648 +mistranslation: 0.571 +semantic: 0.544 +arm: 0.541 +network: 0.426 +performance: 0.331 +register: 0.294 +files: 0.286 +ppc: 0.261 +permissions: 0.250 +socket: 0.234 +vnc: 0.216 +boot: 0.212 +x86: 0.191 +peripherals: 0.190 +PID: 0.178 +debug: 0.163 +virtual: 0.162 +i386: 0.135 +user-level: 0.132 +VMM: 0.073 +TCG: 0.068 +hypervisor: 0.063 +risc-v: 0.059 +assembly: 0.054 +KVM: 0.009 + +Kernel Panic Unable to mount root fs on unknown-block(31,3) + +Using the latest qemu: +qemu-system-arm.exe -kernel C:\Users\a\Downloads\kernel-qemu-4.4.34-jessie -cpu arm1176 -m 256 -machine versatilepb -cdrom C:\Users\a\Downloads\picore-9.0.3.img + +Gives error: +Kernel Panic Unable to mount root fs on unknown-block(31,3) + +I have tried different ARMv6 ARMv7 images/kernels with the same result. + + + +Did it work with a previous version of QEMU? If yes, which version? And since you're using -kernel ... don't you maybe have to use -initrd here, too? + +That's a guest error message, meaning it couldn't mount the root filesystem. This is almost certainly because you're not telling the guest kernel the right argument for where to find its rootfs (which you've provided with -cdrom). Googling suggests that you're getting this kernel from https://github.com/dhruvvyas90/qemu-rpi-kernel -- which has a readme file which tells you what command line options you need to use. Specifically: + * you need to have 'root=/dev/sda2' in your -append argument + * you want to use -hda rather than -cdrom + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1770 b/results/classifier/118/graphic/1770 new file mode 100644 index 000000000..e7161321e --- /dev/null +++ b/results/classifier/118/graphic/1770 @@ -0,0 +1,52 @@ +graphic: 0.869 +device: 0.842 +architecture: 0.800 +PID: 0.795 +x86: 0.762 +semantic: 0.703 +performance: 0.696 +network: 0.591 +socket: 0.529 +permissions: 0.522 +register: 0.511 +vnc: 0.510 +user-level: 0.502 +kernel: 0.435 +mistranslation: 0.432 +debug: 0.428 +files: 0.426 +boot: 0.417 +peripherals: 0.406 +i386: 0.332 +ppc: 0.253 +hypervisor: 0.249 +VMM: 0.224 +assembly: 0.219 +TCG: 0.175 +risc-v: 0.173 +virtual: 0.166 +arm: 0.129 +KVM: 0.056 + +Wrong unpacked structure for epoll_event on qemu-or1k (openrisc) +Description of problem: +When using cmake automoc, the process will infinite loop waiting for epoll_events. +Steps to reproduce: +1. Try to compile cmake with qt5 support +2. The build process will freeze when "Automatic MOC" is invoked +Additional information: +The problem is that or1k has a "packed" epoll_event structure, so it should be also packed in target_epoll_event structure. +Following the (very trivial) patch: +``` +--- qemu-20230327/linux-user/syscall_defs.h.orig 2023-03-27 15:41:42.000000000 +0200 ++++ qemu-20230327/linux-user/syscall_defs.h 2023-06-30 17:29:39.034322213 +0200 +@@ -2714,7 +2709,7 @@ + #define FUTEX_CMD_MASK ~(FUTEX_PRIVATE_FLAG | FUTEX_CLOCK_REALTIME) + + #ifdef CONFIG_EPOLL +-#if defined(TARGET_X86_64) ++#if defined(TARGET_X86_64) || defined(TARGET_OPENRISC) + #define TARGET_EPOLL_PACKED QEMU_PACKED + #else + #define TARGET_EPOLL_PACKED +``` diff --git a/results/classifier/118/graphic/1775011 b/results/classifier/118/graphic/1775011 new file mode 100644 index 000000000..6a3de7fd7 --- /dev/null +++ b/results/classifier/118/graphic/1775011 @@ -0,0 +1,54 @@ +graphic: 0.870 +x86: 0.842 +boot: 0.767 +architecture: 0.729 +device: 0.728 +performance: 0.629 +debug: 0.604 +i386: 0.570 +PID: 0.566 +mistranslation: 0.555 +semantic: 0.530 +ppc: 0.480 +permissions: 0.422 +user-level: 0.399 +register: 0.396 +arm: 0.384 +files: 0.379 +vnc: 0.369 +peripherals: 0.366 +network: 0.363 +risc-v: 0.318 +socket: 0.317 +TCG: 0.307 +hypervisor: 0.300 +VMM: 0.282 +virtual: 0.234 +kernel: 0.233 +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/118/graphic/1778182 b/results/classifier/118/graphic/1778182 new file mode 100644 index 000000000..9332317fa --- /dev/null +++ b/results/classifier/118/graphic/1778182 @@ -0,0 +1,66 @@ +graphic: 0.863 +semantic: 0.792 +architecture: 0.744 +device: 0.639 +mistranslation: 0.615 +performance: 0.614 +network: 0.541 +ppc: 0.532 +user-level: 0.496 +peripherals: 0.493 +virtual: 0.478 +PID: 0.428 +permissions: 0.421 +kernel: 0.415 +register: 0.403 +debug: 0.393 +boot: 0.391 +files: 0.384 +socket: 0.335 +arm: 0.292 +vnc: 0.287 +i386: 0.263 +risc-v: 0.256 +x86: 0.233 +hypervisor: 0.197 +TCG: 0.142 +VMM: 0.111 +KVM: 0.090 +assembly: 0.079 + +qemu-system-aarch64 shows black framebuffer window on minimal bare metal example on SDL but not on VNC + +QEMU v2.12.0, Ubuntu 18.04 host. + +Build QEMU and the bare metal image exactly as described at: https://raspberrypi.stackexchange.com/revisions/85135/4 with: + +Then cd into example 09_framebuffer. + +Now if I do: + +../../qemu/aarch64-softmmu/qemu-system-aarch64 -M raspi3 -kernel kernel8.img -serial stdio + +the SDL window shows up black. + +However, if I use VNC: + +../../qemu/aarch64-softmmu/qemu-system-aarch64 -M raspi3 -kernel kernel8.img -serial stdio -vnc :1 +vinagre :5901 + +an image of Homer Simpson appears as expected. + +Therefore, I think this must be a QEMU / SDL bug instead of the repository, since we get different behaviors with `-vnc` and with SDL. + +Things that work: + +- https://github.com/cirosantilli/linux-kernel-module-cheat/tree/741f5215e9515c0d7179671f49fe1781f94e70e3#graphic-mode-arm which shows the Penguin with the Linux kernel, after hacking that repo up to use the exact same QEMU executable as reported here +- the UART examples on the image repo: https://github.com/bztsrc/raspi3-tutorial/tree/9e5611a624b3037788d5b29d951304938bff13ea/05_uart0 + +Works for me with both the GTK display and '-display sdl' with current head-of-git QEMU... + + +Hi; I'm moving this bug to 'incomplete', because I was never able to repro it -- gtk and sdl displays both worked for me. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1779649 b/results/classifier/118/graphic/1779649 new file mode 100644 index 000000000..eecfb2c57 --- /dev/null +++ b/results/classifier/118/graphic/1779649 @@ -0,0 +1,43 @@ +graphic: 0.833 +kernel: 0.783 +device: 0.772 +ppc: 0.611 +mistranslation: 0.561 +socket: 0.561 +network: 0.546 +vnc: 0.542 +architecture: 0.540 +risc-v: 0.516 +semantic: 0.514 +register: 0.505 +performance: 0.478 +PID: 0.472 +hypervisor: 0.448 +boot: 0.420 +peripherals: 0.406 +permissions: 0.403 +arm: 0.383 +VMM: 0.355 +i386: 0.349 +user-level: 0.345 +files: 0.302 +virtual: 0.283 +x86: 0.260 +TCG: 0.254 +debug: 0.217 +assembly: 0.197 +KVM: 0.074 + +Suspending a domain works with a 3.16 gues kernel but not with a 4.16 one + +Suspending a domain with `systemctl suspend` works with a guest 3.16 kernel (jessie), the domain goes into `pmsuspend` in libvirt but doesn't work anymore with a 4.16 one (sid) where: + - With a QXL card: the spice display just goes black and the domain stays `running` in libvirt but is "dead" + - With a VGA card: the screen goes black and comes back immediately, the domain stays fine + +Qemu: Master, 281bd281222776229d5dbf84d1a5c6d8d9d2a34b + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1781211 b/results/classifier/118/graphic/1781211 new file mode 100644 index 000000000..d0eff5489 --- /dev/null +++ b/results/classifier/118/graphic/1781211 @@ -0,0 +1,56 @@ +graphic: 0.814 +x86: 0.798 +kernel: 0.765 +register: 0.747 +device: 0.698 +architecture: 0.641 +performance: 0.582 +semantic: 0.578 +files: 0.503 +PID: 0.494 +socket: 0.442 +arm: 0.427 +vnc: 0.419 +permissions: 0.372 +boot: 0.363 +virtual: 0.345 +ppc: 0.331 +mistranslation: 0.328 +debug: 0.307 +network: 0.294 +VMM: 0.275 +risc-v: 0.266 +user-level: 0.258 +peripherals: 0.218 +TCG: 0.194 +hypervisor: 0.141 +i386: 0.118 +KVM: 0.112 +assembly: 0.071 + +HAXM acceleration does not work at all. + +I have qemu windows build 2.12.90, haxm 7.2.0. Ubuntu, nor arch linux does not works when i turn on hax acceleration. Permanent kernel panics, black screen freezing and other crashes happens when i run qemu. +Qemu crashed with hax - when i ran it from iso. It crashed on already installed system - it's not matters. + +Versions: +archlinux-2018.07.01-x86_64 +ubuntu-18.04-live-server-amd64.iso + +I run qemu-system-x86_64.exe binary. + +My CPU: +core i7 2600k + +See screenshot + + + +After some time I decided it is haxm bug - so i created the same issue on haxm project too + +https://github.com/intel/haxm/issues/74 + +This issue has been fixed in HAXM, see: +"save/restore FPU registers in VM entry/exit" +https://github.com/intel/haxm/commit/6c2cd4d79d + diff --git a/results/classifier/118/graphic/1781515 b/results/classifier/118/graphic/1781515 new file mode 100644 index 000000000..7501fb5d9 --- /dev/null +++ b/results/classifier/118/graphic/1781515 @@ -0,0 +1,69 @@ +graphic: 0.969 +x86: 0.965 +user-level: 0.926 +architecture: 0.924 +virtual: 0.906 +KVM: 0.902 +mistranslation: 0.897 +device: 0.895 +performance: 0.875 +PID: 0.853 +semantic: 0.853 +ppc: 0.852 +kernel: 0.840 +permissions: 0.824 +boot: 0.815 +risc-v: 0.806 +hypervisor: 0.798 +files: 0.773 +network: 0.758 +register: 0.757 +socket: 0.754 +arm: 0.753 +vnc: 0.740 +peripherals: 0.738 +i386: 0.723 +debug: 0.717 +VMM: 0.677 +assembly: 0.582 +TCG: 0.505 + +Resolution switch leads to the screen/image being corrupted + +I am currently using QEMU on a Arch Linux host, the guest OS is also Arch Linux. + +The QEMU version is currently 2.12.0-2 packaged by Arch Linux, the command line I'm using to fire an Arch VM is: + +$ qemu-system-x86_64 -enable-kvm -hda archlinux.qcow2 -m 4G -smp 4 + +The problem I'm currently having is, after firing the VM and running startx I want to change the resolution to the native resolution, which is 1366x768 on my ThinkPad T450, however, after changing the resolution the image on the guest gets corrupted and it's impossible to see anything. + +At this point I can only turn off the VM. The only workaround I found is to start the VM with -vga virtio. + +The problem in this case occurs with -vga std which is the default video driver. + +Switching the resolution with -vga std was working fine before, I'm not sure on which version it started having this issue, but it should be on a recent version. + +I use the intel i915 drivers on the host OS. + +Hi Diego, + +It seems this is a known limitation[1] because horizontal width is not a multiple of 8, try 1360x768 as the nearest resolution, which works for me on guests not supporting QXL drivers. + +Regards. + +[1] Proposed patch from 2013: https://lists.gnu.org/archive/html/qemu-devel/2013-03/msg02732.html + +Hi Francisco, thanks for your quick reply. + +I've tried `xrandr --output Virtual-1 --mode 1360x768' with -vga std and I also get a corrupted image. + +I'm attaching a screenshot of what the screen corruption looks like after changing the resolution. + +Thanks. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1785698 b/results/classifier/118/graphic/1785698 new file mode 100644 index 000000000..576fc20a4 --- /dev/null +++ b/results/classifier/118/graphic/1785698 @@ -0,0 +1,615 @@ +graphic: 0.955 +hypervisor: 0.935 +register: 0.923 +vnc: 0.921 +debug: 0.919 +assembly: 0.906 +virtual: 0.902 +architecture: 0.900 +arm: 0.893 +TCG: 0.891 +risc-v: 0.887 +device: 0.887 +socket: 0.885 +PID: 0.882 +permissions: 0.878 +peripherals: 0.875 +network: 0.857 +performance: 0.844 +ppc: 0.842 +files: 0.833 +boot: 0.821 +kernel: 0.806 +x86: 0.803 +semantic: 0.794 +KVM: 0.788 +VMM: 0.763 +mistranslation: 0.720 +user-level: 0.704 +i386: 0.509 + +Solaris build error: unknown type name ‘gcry_error_t’ + +Building qemu 2.12.0 on a Sun Oracle Enterprise M3000 SPARC64 VII, opencsw toolchain and gcc 7.3.0, gmake fails with a bunch of related errors all in cypher-gcrypt.c: + +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:262:32: error: ‘gcry_cipher_hd_t’ undeclared (first use in this function); did you mean ‘gcry_cipher_info’? + err = gcry_cipher_encrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~~~~~~~~~~~~~~ + gcry_cipher_info +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:262:49: error: expected ‘)’ before ‘ctx’ + err = gcry_cipher_encrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~ +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:262:11: error: too few arguments to function ‘gcry_cipher_encrypt’ + err = gcry_cipher_encrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~~~~~~~~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:25:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/usr/include/gcrypt.h:566:5: note: declared here + int gcry_cipher_encrypt (GcryCipherHd h, + ^~~~~~~~~~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c: In function ‘qcrypto_gcrypt_xts_decrypt’: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:271:5: error: unknown type name ‘gcry_error_t’; did you mean ‘g_error’? + gcry_error_t err; + ^~~~~~~~~~~~ + g_error +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:272:32: error: ‘gcry_cipher_hd_t’ undeclared (first use in this function); did you mean ‘gcry_cipher_info’? + err = gcry_cipher_decrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~~~~~~~~~~~~~~ + gcry_cipher_info +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:272:49: error: expected ‘)’ before ‘ctx’ + err = gcry_cipher_decrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~ +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:272:11: error: too few arguments to function ‘gcry_cipher_decrypt’ + err = gcry_cipher_decrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~~~~~~~~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:25:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/usr/include/gcrypt.h:571:5: note: declared here + int gcry_cipher_decrypt (GcryCipherHd h, + ^~~~~~~~~~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c: In function ‘qcrypto_gcrypt_cipher_encrypt’: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:284:5: error: unknown type name ‘gcry_error_t’; did you mean ‘g_error’? + gcry_error_t err; + ^~~~~~~~~~~~ + g_error +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:293:21: warning: passing argument 1 of ‘xts_encrypt’ makes pointer from integer without a cast [-Wint-conversion] + xts_encrypt(ctx->handle, ctx->tweakhandle, + ^~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:22:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/export/home/denber/qemu-2.12.0/include/crypto/xts.h:73:6: note: expected ‘const void *’ but argument is of type ‘int’ + void xts_encrypt(const void *datactx, + ^~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:293:34: warning: passing argument 2 of ‘xts_encrypt’ makes pointer from integer without a cast [-Wint-conversion] + xts_encrypt(ctx->handle, ctx->tweakhandle, + ^~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:22:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/export/home/denber/qemu-2.12.0/include/crypto/xts.h:73:6: note: expected ‘const void *’ but argument is of type ‘int’ + void xts_encrypt(const void *datactx, + ^~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:298:35: warning: passing argument 1 of ‘gcry_cipher_encrypt’ makes pointer from integer without a cast [-Wint-conversion] + err = gcry_cipher_encrypt(ctx->handle, + ^~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:25:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/usr/include/gcrypt.h:566:5: note: expected ‘GcryCipherHd {aka struct gcry_cipher_handle *}’ but argument is of type ‘int’ + int gcry_cipher_encrypt (GcryCipherHd h, + ^~~~~~~~~~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c: In function ‘qcrypto_gcrypt_cipher_decrypt’: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:320:5: error: unknown type name ‘gcry_error_t’; did you mean ‘g_error’? + gcry_error_t err; + ^~~~~~~~~~~~ + g_error +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:329:21: warning: passing argument 1 of ‘xts_decrypt’ makes pointer from integer without a cast [-Wint-conversion] + xts_decrypt(ctx->handle, ctx->tweakhandle, + ^~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:22:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/export/home/denber/qemu-2.12.0/include/crypto/xts.h:51:6: note: expected ‘const void *’ but argument is of type ‘int’ + void xts_decrypt(const void *datactx, + ^~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:329:34: warning: passing argument 2 of ‘xts_decrypt’ makes pointer from integer without a cast [-Wint-conversion] + xts_decrypt(ctx->handle, ctx->tweakhandle, + ^~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:22:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/export/home/denber/qemu-2.12.0/include/crypto/xts.h:51:6: note: expected ‘const void *’ but argument is of type ‘int’ + void xts_decrypt(const void *datactx, + ^~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:334:35: warning: passing argument 1 of ‘gcry_cipher_decrypt’ makes pointer from integer without a cast [-Wint-conversion] + err = gcry_cipher_decrypt(ctx->handle, + ^~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:25:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/usr/include/gcrypt.h:571:5: note: expected ‘GcryCipherHd {aka struct gcry_cipher_handle *}’ but argument is of type ‘int’ + int gcry_cipher_decrypt (GcryCipherHd h, + ^~~~~~~~~~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c: In function ‘qcrypto_gcrypt_cipher_setiv’: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:353:5: error: unknown type name ‘gcry_error_t’; did you mean ‘g_error’? + gcry_error_t err; + ^~~~~~~~~~~~ + g_error +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:365:19: warning: implicit declaration of function ‘gcry_cipher_setctr’; did you mean ‘gcry_cipher_setiv’? [-Wimplicit-function-declaration] + err = gcry_cipher_setctr(ctx->handle, iv, niv); + ^~~~~~~~~~~~~~~~~~ + gcry_cipher_setiv +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:365:19: warning: nested extern declaration of ‘gcry_cipher_setctr’ [-Wnested-externs] +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:372:13: warning: implicit declaration of function ‘gcry_cipher_reset’; did you mean ‘gcry_cipher_close’? [-Wimplicit-function-declaration] + gcry_cipher_reset(ctx->handle); + ^~~~~~~~~~~~~~~~~ + gcry_cipher_close +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:372:13: warning: nested extern declaration of ‘gcry_cipher_reset’ [-Wnested-externs] +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:373:19: warning: passing argument 1 of ‘gcry_cipher_ctl’ makes pointer from integer without a cast [-Wint-conversion] + err = gcry_cipher_setiv(ctx->handle, iv, niv); + ^~~~~~~~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:25:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/usr/include/gcrypt.h:540:5: note: expected ‘GcryCipherHd {aka struct gcry_cipher_handle *}’ but argument is of type ‘int’ + int gcry_cipher_ctl( GcryCipherHd h, int cmd, void *buffer, size_t buflen); + ^~~~~~~~~~~~~~~ +gmake: *** [/export/home/denber/qemu-2.12.0/rules.mak:67: crypto/cipher.o] Error 1 + +--------------------------------------------------------------------- + +I do have libgcrypt, libgcrypt_dev, and libgcrypt_utils installed from opencsw. + +It turns out I needed +#include </opt/csw/include/gcrypt.h> +in crypto/cipher-grypt.c + +However, now I'm stuck on + +# gmake +mkdir -p dtc/libfdt +mkdir -p dtc/tests +Bad string + LINK qemu-nbd +ld: fatal: library -lutil: not found +ld: fatal: file processing errors. No output written to qemu-nbd +collect2: error: ld returned 1 exit status +gmake: *** [/export/home/denber/qemu-2.12.0/rules.mak:122: qemu-nbd] Error 1 +# + +I can't find who's asking for -lutil. There's no mention of it in qemu-nbd.c. Can someone tell me where thsi need for -lutil is coming from? + + +Hi, compiling on Solaris is currently unsupported since no developer has access to a Solaris system (see https://wiki.qemu.org/ChangeLog/3.0#Warning:_unsupported_host_systems for example). +Concerning -lutil, there is a check in the "configure" script: + +if test "$darwin" != "yes" -a "$mingw32" != "yes" -a "$solaris" != yes -a \ + "$haiku" != "yes" ; then + libs_softmmu="-lutil $libs_softmmu" +fi + +Maybe something went wrong with the detection of Solaris there? What's the content of the $solaris variable at that point in time? + +Adding #include </opt/csw/include/gcrypt.h> is definitely wrong. You are instead missing the right -I include path. The libgcrypt-config command should be in $PATH, and should print "-I/opt/csw/include" args when running "libgcrypt-config --cflags". If that doesn't happen, then the gcrypt installation is broken. + + +Ah, I see: + +"in a future QEMU release we may drop support for those hosts unless somebody volunteers to help us with maintaining them (and can provide build/CI machines)." + +OK, so I happily volunteer an account on my machine to help maintain this. + +"What's the content of the $solaris variable at that point in time?" + +How do I tell that? + +$solaris seems to be set in a line earlier on: + +case $targetos in +... +SunOS) + solaris="yes" + +and targetos is set before that by + +elif check_define __sun__ ; then + targetos='SunOS' + +but I don't know what "check_define __sun__" is. I am not a good Makefile reader. + +"The libgcrypt-config command should be in $PATH" + +I'm sorry - I don't understand. Isn't $PATH a list of directories? I need to put a command in there? I'm clearly missing something here. + +Can you simply put a + + echo XXXX $solaris XXXX + +right before the "if test "$darwin" != "yes" -a "$mingw32" != "yes" -a "$solaris" != yes -a" line in the configure script, and then run configure again? You then should see the contents of the $solaris variable. + +And what do you get if you run + + libgcrypt-config --cflags + +and + + libgcrypt-config --libs + +in your shell? + +"echo XXXX $solaris XXXX" + +That gives: + +# /usr/xpg4/bin/sh ../configure --extra-cflags="-m32" --target-list=x86_64-softmmu +XXXX yes XXXX +Install prefix /usr/local +BIOS directory /usr/local/share/qemu +firmware path /usr/local/share/qemu-firmware +binary directory /usr/local/bin +library directory /usr/local/lib +module directory /usr/local/lib/qemu +libexec directory /usr/local/libexec +include directory /usr/local/include +config directory /usr/local/etc +local state directory /usr/local/var +Manual directory /usr/local/share/man +ELF interp prefix /usr/gnemul/qemu-%M +... + +Then: + +# libgcrypt-config --cflags +-I/opt/csw/include +# libgcrypt-config --libs +-L/opt/csw/lib -lgcrypt -lgpg-error +# echo $SHELL +/bin/bash +# bash --version +GNU bash, version 4.3.33(1)-release (sparc-sun-solaris2.10) +Copyright (C) 2013 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +# + +Anyone? My offer of free use of my machine to support Qemu on Solaris still stands. Perhaps I'm asking in the wrong place? + +For providing a Solaris build machine, you best get in touch with Peter Maydell (see MAINTAINERS file for his mail address). + +Now for your build problems, it seems like "libgcrypt-config --cflags" already should add /opt/csw/include to the list of header search paths, so I wonder why the "#include <gcrypt.h>" does not pick up that file yet and you had to add "#include </opt/csw/include/gcrypt.h>" instead? Is there maybe another gcrypt.h file somewhere else on your system which conflicts with the one from /opt/csw/include ? + +Concerning the "-lutil" problem - no clue where this is coming from. Could you maybe try to compile with "gmake V=1" and post the line where the executable is linked? Maybe that gives some more indication what is going on here... + + + +On 08-13-2018 4:14 AM, Thomas Huth wrote: +> For providing a Solaris build machine, you best get in touch with Peter +> Maydell (see MAINTAINERS file for his mail address). +I notice he already checked in later in my inbox. I'll reply to that there. +> +> Now for your build problems, it seems like "libgcrypt-config --cflags" +> already should add /opt/csw/include to the list of header search paths, +> so I wonder why the "#include <gcrypt.h>" does not pick up that file yet +> and you had to add "#include </opt/csw/include/gcrypt.h>" instead? Is +> there maybe another gcrypt.h file somewhere else on your system which +> conflicts with the one from /opt/csw/include ? +Well this is odd but I was poking around trying to resolve a bunch of +syntax errors in the Makefiles. This is usually the result of a wrong +sh being called. I've had some luck in the past building other things +by adding a line "!#/usr/xpg4/bin/sh" at the top of the sh file but that +trick did not work for qemu. So I finally took the default sh, which is +/usr/bin/sh (which is a link to /sbin/sh) and instead linked it directly +to /usr/xpg4/bin/sh. That immediately took care of all the syntax +errors and the gcrypt error too. I don't know why qemu is picky about +POSIX, but there you have it. +> +> Concerning the "-lutil" problem - no clue where this is coming from. +> Could you maybe try to compile with "gmake V=1" and post the line where +> the executable is linked? Maybe that gives some more indication what is +> going on here... +This will probably make you cringe, but what I ended up doing was simply +copying some random .so file in /opt/csw/lib and calling it libutil.so. +The linker then seemed happy and that error went away. I figure that if +someone is actually using lutil I will get a runtime error, once I get +it running, if I ever get it running. Then I'll be able to tell who is +calling it and what they're trying to do. It may be that no one is +using it. I saw some post on the web to the effect that lutil should +just be commented out in Solaris. I was unable to figure out from the +linker error the source of lutil. + +I now have a new problem: dtc/checks.c won't compile because it can't +find strnlen. So I put in #include <string.h>. Still wouldn't +compile. So I looked in /usr/include/string.h and sure enough, strnlen +is missing. I'm like, what the heck? So I ended up providing the +source code of strnlen at the top of checks.c. This was also a problem +in fdt_ro.c. It's that sort of thing. Now it's compiling again. I +configured without any target options, so it's making everything. And I +forgot to give gmake a -j so it's taking a while. + + - Michele + + + +Well my gmake finally went all the way to the end building all of the +guest architectures but I didn't see a qemu executable (unless it isn't +called qemu). I ran gmake again to see what happened and all I got was +this: + +# gmake +mkdir -p dtc/libfdt +mkdir -p dtc/tests +Bad string +# + +I then ran gmake V=1. That didn't really help:: + + +(cd /export/home/denber/qemu-2.12.0; if test -n ""; then pkgvers=""; +else if test -d .git; then pkgvers=$(git describe --match 'v*' +2>/dev/null | tr -d '\n'); if ! git diff-index --quiet HEAD &>/dev/null; +then pkgvers="${pkgvers}-dirty"; fi; fi; fi; printf "#define +QEMU_PKGVERSION \"${pkgvers}\"\n"; if test -n "${pkgvers}"; then printf +'#define QEMU_FULL_VERSION QEMU_VERSION " (" QEMU_PKGVERSION ")"\n'; +else printf '#define QEMU_FULL_VERSION QEMU_VERSION\n'; fi; ) > +qemu-version.h.tmp +if ! cmp -s qemu-version.h qemu-version.h.tmp; then mv +qemu-version.h.tmp qemu-version.h; else rm qemu-version.h.tmp; fi +mkdir -p dtc/libfdt +mkdir -p dtc/tests +gmake -I/export/home/denber/qemu-2.12.0/dtc +VPATH=/export/home/denber/qemu-2.12.0/dtc -C dtc V="1" +LIBFDT_srcdir=/export/home/denber/qemu-2.12.0/dtc/libfdt +CPPFLAGS="-I/export/home/denber/qemu-2.12.0/build/dtc +-I/export/home/denber/qemu-2.12.0/dtc +-I/export/home/denber/qemu-2.12.0/dtc/libfdt" CFLAGS="-O2 +-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -I/opt/csw/include/pixman-1 +-I/export/home/denber/qemu-2.12.0/dtc/libfdt -D_REENTRANT -D_PTHREADS +-I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -m32 +-mv8plus -mcpu=ultrasparc -std=gnu99 -D__EXTENSIONS__ +-D_XOPEN_SOURCE=600 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 +-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef +-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common +-fwrapv -Wexpansion-to-defined -Wendif-labels -Wno-shift-negative-value +-Wno-missing-include-dirs -Wempty-body -Wnested-externs +-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers +-Wold-style-declaration -Wold-style-definition -Wtype-limits +-fstack-protector-strong -I/opt/csw/include -I/usr/include/libpng12 +-I/export/home/denber/qemu-2.12.0/capstone/include +-I/export/home/denber/qemu-2.12.0/tests" LDFLAGS="-m32 -mv8plus -g " +ARFLAGS="rv" CC="gcc" AR="ar" LD="ld" +BUILD_DIR=/export/home/denber/qemu-2.12.0/build libfdt/libfdt.a +gmake[1]: Entering directory '/export/home/denber/qemu-2.12.0/build/dtc' +Bad string +gmake[1]: 'libfdt/libfdt.a' is up to date. +gmake[1]: Leaving directory '/export/home/denber/qemu-2.12.0/build/dtc' +... + +It doesn't say "Error: Bad string", it just says "Bad string". Is that +even an error? A web search for this turned up nothing and the string +"Bad string" does not seem to appear in the entire qemu directory. I'm +not sure what's going on now. There seems to be something in the dtc +subdirectory it doesn't like. + + - Michele + + + +On 13 August 2018 at 19:58, Michele Denber <email address hidden> wrote: +> I don't know why qemu is picky about +> POSIX, but there you have it. + +We do assume a posix shell and that that shell is /bin/sh. +We may have bugs where we assume non-posix behaviour +from it, since almost all users are going to be on systems +where /bin/sh is bash or dash or whatever the BSD /bin/sh is. + +(dtc is a sort-of-third-party module, not part of QEMU +proper.) + +thanks +-- PMM + + +On 08-14-2018 4:42 AM, Peter Maydell wrote: +> +> We do assume a posix shell and that that shell is /bin/sh. +> We may have bugs where we assume non-posix behaviour +> from it, since almost all users are going to be on systems +> where /bin/sh is bash or dash or whatever the BSD /bin/sh is. +Apparently Solaris is different in that regard (among others). +> +> (dtc is a sort-of-third-party module, not part of QEMU +> proper.) +I notice in the Makefile in dtc/ that it's calling python. My default +python is 2.6.9. I found some discussion about qemu moving to python +3. Could this be the problem? Or is this dtc stuff really necessary? +Is there some way to comment it out just to see what happens? I didn't +see any mention of it in the configure help. + +I feel like I'm getting pretty close to success here. + + - Michele + + + +> I notice in the Makefile in dtc/ that it's calling python. My default +> python is 2.6.9. I found some discussion about qemu moving to python +> 3. Could this be the problem? + +We require either Python 2.7.x, or Python 3.x versions. Support for 2.6.x was dropped I'm afraid. + +On 14 August 2018 at 18:44, Michele Denber <email address hidden> wrote: +> On 08-14-2018 4:42 AM, Peter Maydell wrote: +>> +>> We do assume a posix shell and that that shell is /bin/sh. +>> We may have bugs where we assume non-posix behaviour +>> from it, since almost all users are going to be on systems +>> where /bin/sh is bash or dash or whatever the BSD /bin/sh is. +> Apparently Solaris is different in that regard (among others). + +Yeah. I'm not sure how much I care about supporting OSes that +decide to be totally different from everybody else, to be honest. +It's the 21st century and POSIX is a thing. + +>> (dtc is a sort-of-third-party module, not part of QEMU +>> proper.) +> I notice in the Makefile in dtc/ that it's calling python. My default +> python is 2.6.9. + +Our Python requirement is 2.7, and configure should check that. +If you're telling configure --python=/some/nondefault/python +then I guess the problem is we're not passing that on to dtc's +build process. + +> Or is this dtc stuff really necessary? + +It is necessary, but only for certain guest CPU types. You can +disable it by passing configure both "--disable-fdt" and also +"--target-list=<some list of targets which doesn't include +any arm, ppc, mips, microblaze or riscv targets>" +(for instance "--target-list=x86_64-softmmu".) + +thanks +-- PMM + + +On 08-14-2018 2:17 PM, Peter Maydell wrote: +> +> dtc stuff really necessary? +> It is necessary, but only for certain guest CPU types. You can +> disable it by passing configure both "--disable-fdt" and also +> "--target-list=<some list of targets which doesn't include +> any arm, ppc, mips, microblaze or riscv targets>" +> (for instance "--target-list=x86_64-softmmu".) +Thanks. Turns out I found where "Bad string" was coming from - there's +a call to "uname -s | tr" in dtc/Makefile and that is known not to work +in Solaris 10.. So I just replaced that with "HOSTOS=SunOS" and that +took care of that. dtc compiled just fine. + +Now I'm getting a "ld: fatal: unrecognized option '--'" linking libfdt +so I'm going to try a different linker. + +Onward :-) + + - Michele + + + + + +> +> +> > I notice in the Makefile in dtc/ that it's calling python. My default +> > python is 2.6.9. I found some discussion about qemu moving to python +> > 3. Could this be the problem? +> +> We require either Python 2.7.x, or Python 3.x versions. Support for +> 2.6.x was dropped I'm afraid. +> +> +Thanks. I upgraded to python 3.3 though that turned out not to be the +problem. I documented the solution here: + +https://bugs.launchpad.net/qemu/+bug/1787012 + + - Michele + + + +Here's a mystery. It looks like I finally have a clean compile - there +are no error messages but I don't see an executable. Is there supposed +to be something called "qemu" somewhere now? I looked in build/, the +top level, and /usr/local/bin/. + +# gmake V=1 +(cd /export/home/denber/qemu-2.12.0; if test -n ""; then pkgvers=""; +else if test -d .git; then pkgvers=$(git describe --match 'v*' +2>/dev/null | tr -d '\n'); if ! git diff-index --quiet HEAD &>/dev/null; +then pkgvers="${pkgvers}-dirty"; fi; fi; fi; printf "#define +QEMU_PKGVERSION \"${pkgvers}\"\n"; if test -n "${pkgvers}"; then printf +'#define QEMU_FULL_VERSION QEMU_VERSION " (" QEMU_PKGVERSION ")"\n'; +else printf '#define QEMU_FULL_VERSION QEMU_VERSION\n'; fi; ) > +qemu-version.h.tmp +if ! cmp -s qemu-version.h qemu-version.h.tmp; then mv +qemu-version.h.tmp qemu-version.h; else rm qemu-version.h.tmp; fi +mkdir -p dtc/libfdt +mkdir -p dtc/tests +gmake -I/export/home/denber/qemu-2.12.0/dtc +VPATH=/export/home/denber/qemu-2.12.0/dtc -C dtc V="1" +LIBFDT_srcdir=/export/home/denber/qemu-2.12.0/dtc/libfdt +CPPFLAGS="-I/export/home/denber/qemu-2.12.0/build/dtc +-I/export/home/denber/qemu-2.12.0/dtc +-I/export/home/denber/qemu-2.12.0/dtc/libfdt" CFLAGS="-O2 +-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -I/opt/csw/include/pixman-1 +-I/export/home/denber/qemu-2.12.0/dtc/libfdt -D_REENTRANT -D_PTHREADS +-I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -m32 +-mv8plus -mcpu=ultrasparc -std=gnu99 -D__EXTENSIONS__ +-D_XOPEN_SOURCE=600 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 +-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef +-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common +-fwrapv -Wexpansion-to-defined -Wendif-labels -Wno-shift-negative-value +-Wno-missing-include-dirs -Wempty-body -Wnested-externs +-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers +-Wold-style-declaration -Wold-style-definition -Wtype-limits +-fstack-protector-strong -I/opt/csw/include -I/usr/include/libpng12 +-I/export/home/denber/qemu-2.12.0/capstone/include +-I/export/home/denber/qemu-2.12.0/tests" LDFLAGS="-m32 -mv8plus -g " +ARFLAGS="rv" CC="gcc" AR="ar" LD="ld" +BUILD_DIR=/export/home/denber/qemu-2.12.0/build libfdt/libfdt.a +gmake[1]: Entering directory '/export/home/denber/qemu-2.12.0/build/dtc' +gmake[1]: 'libfdt/libfdt.a' is up to date. +gmake[1]: Leaving directory '/export/home/denber/qemu-2.12.0/build/dtc' +gmake -C /export/home/denber/qemu-2.12.0/capstone CAPSTONE_SHARED=no +BUILDDIR="/export/home/denber/qemu-2.12.0/build/capstone" CC="gcc" +AR="ar" LD="ld" RANLIB="ranlib" CFLAGS="-O2 -U_FORTIFY_SOURCE +-D_FORTIFY_SOURCE=2 -g -I/opt/csw/include/pixman-1 +-I/export/home/denber/qemu-2.12.0/dtc/libfdt -D_REENTRANT -D_PTHREADS +-I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -m32 +-mv8plus -mcpu=ultrasparc -std=gnu99 -D__EXTENSIONS__ +-D_XOPEN_SOURCE=600 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 +-D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv +-fstack-protector-strong -I/opt/csw/include -I/usr/include/libpng12 +-I/export/home/denber/qemu-2.12.0/capstone/include +-I/export/home/denber/qemu-2.12.0/tests -DCAPSTONE_USE_SYS_DYN_MEM +-DCAPSTONE_HAS_ARM -DCAPSTONE_HAS_ARM64 -DCAPSTONE_HAS_POWERPC +-DCAPSTONE_HAS_X86" BUILD_DIR=/export/home/denber/qemu-2.12.0/build +/export/home/denber/qemu-2.12.0/build/capstone/libcapstone.a +gmake[1]: Entering directory '/export/home/denber/qemu-2.12.0/capstone' +gmake[1]: '/export/home/denber/qemu-2.12.0/build/capstone/libcapstone.a' +is up to date. +gmake[1]: Leaving directory '/export/home/denber/qemu-2.12.0/capstone' +gmake BUILD_DIR=/export/home/denber/qemu-2.12.0/build -C x86_64-softmmu +V="1" TARGET_DIR="x86_64-softmmu/" all +gmake[1]: Entering directory +'/export/home/denber/qemu-2.12.0/build/x86_64-softmmu' +gmake[1]: Leaving directory +'/export/home/denber/qemu-2.12.0/build/x86_64-softmmu' +# + +I even did a gmake clean and then gmake again. No change - no errors +and no executable. ??? + + - Michele + + + + +The executables are created in the subdirectories for each target, so x86_64-softmmu/qemu-system-x86_64 and so on. + + +On 08-15-2018 6:50 AM, Peter Maydell wrote: +> The executables are created in the subdirectories for each target, so +> x86_64-softmmu/qemu-system-x86_64 and so on. +> +Oh duh! :-) I'm really glad I asked. I've been trying to figure out +why there was no executable and no errors. Sure enough, I found +qemu-system-x86_64 right there in the x86_64-softmmu directory. I ran +that and it started right up. I guess I was thinking more along the +lines of VirtualBox where you start one program and choose a VM from +there. Thanks! + + - Michele + + + +libutil should not be linked on Solaris, see https://bugs.launchpad.net/qemu/+bug/1777252 + +Right, we've got a separate bug for libutil already, and as far as I can see, all the other problems here were due to using the non-POSIX compliant shell etc., so let's close this bug here and track the libutil problem in the other bug. + +Indeed. Almost all of the problems I was having were due to an incomplete understanding on my part of the way Solaris handles POSIX. Once I figured that out, everything quickly fell into place. + diff --git a/results/classifier/118/graphic/1787 b/results/classifier/118/graphic/1787 new file mode 100644 index 000000000..a1ec51d49 --- /dev/null +++ b/results/classifier/118/graphic/1787 @@ -0,0 +1,43 @@ +graphic: 0.973 +device: 0.847 +semantic: 0.737 +debug: 0.681 +performance: 0.661 +i386: 0.570 +PID: 0.566 +files: 0.565 +network: 0.540 +vnc: 0.529 +ppc: 0.523 +risc-v: 0.492 +VMM: 0.483 +user-level: 0.471 +arm: 0.464 +peripherals: 0.461 +x86: 0.451 +architecture: 0.451 +permissions: 0.435 +KVM: 0.422 +virtual: 0.416 +socket: 0.414 +hypervisor: 0.377 +boot: 0.369 +TCG: 0.345 +mistranslation: 0.341 +kernel: 0.305 +register: 0.259 +assembly: 0.190 + +Qemu asan test make vm crash when using qxl and spice +Description of problem: +When I tested QEMU with asan, the vm crash. The error message is as follows： + +Steps to reproduce: +1.Start the vm with qxl and spice. +2.Attach the vm with vnc and spice. +3.Placed for more than three days. +4.Operation on spice client and possible reproduce this bug. +Additional information: +https://github.com/qemu/qemu/blob/44f28df24767cf9dca1ddc9b23157737c4cbb645/ui/cursor.c#L112 +I think the reason for the problem is that the cursor pointer was not set to NULL when qemu call cursor_put. But I don't know what situation will trigger this error. +This error is difficult to reproduce by natural. diff --git a/results/classifier/118/graphic/1787070 b/results/classifier/118/graphic/1787070 new file mode 100644 index 000000000..6496c86fe --- /dev/null +++ b/results/classifier/118/graphic/1787070 @@ -0,0 +1,87 @@ +graphic: 0.905 +permissions: 0.875 +user-level: 0.869 +peripherals: 0.852 +register: 0.841 +TCG: 0.833 +hypervisor: 0.824 +x86: 0.816 +assembly: 0.814 +virtual: 0.812 +device: 0.809 +debug: 0.808 +ppc: 0.804 +KVM: 0.801 +risc-v: 0.796 +performance: 0.792 +boot: 0.790 +socket: 0.790 +vnc: 0.785 +network: 0.785 +architecture: 0.774 +semantic: 0.747 +PID: 0.735 +arm: 0.732 +mistranslation: 0.674 +kernel: 0.622 +files: 0.621 +VMM: 0.603 +i386: 0.443 + +Guests using the qxl-vga are freezing + +I have noticed that guests using qxl-vga are freezing. They may freeze after a few minutes or after many hours. The freeze consists of the entire system hanging, except the cursor, but the cursor animation stops too. Changing to tty is not possible after this. There are three things noticed in common on the guests when they freeze: + +-The guest is using the QXL VGA (freezes weren't observed with other VGAs); +-A new workload is starting; +-The mouse cursor is the animated as the one of loading. For example, https://i.imgur.com/raQFteG.png + +The host is Xubuntu 18.04 amd64, QEMU version is 3.0.0-dirty. The guests tested were: + +-openSUSE Tumbleweed; +-openSUSE Leap 15; +-Xubuntu 18.04 Bionic Beaver; +-CentOS 7. + +With openSUSE guests, the install process couldn't even be finished, as the installer would freeze. There were 2 GB of available memory (checked in a tty before the freeze) and netconsole was enabled. Unfortunately, it was impossible to obtain any information from them. This is an image of one openSUSE guest frozen: https://i.imgur.com/ZP0eQKq.png + +The command line used was: + +qemu-system-x86_64 -nodefaults -m 3072 -M pc,usb=true -accel kvm -cpu host -smp cores=2,threads=2 -device qemu-xhci -drive id=centusb,if=none,file=leap.qcow2 -device usb-storage,id=centusb,drive=centusb -netdev user,id=n0 -device usb-tablet,id=usbtablet -device e1000,netdev=n0 -device usb-audio,id=usbaudio -device qxl-vga,xres=1366,yres=768 -display gtk -monitor vc -serial vc -cdrom "openSUSE-Leap-15.0-DVD-x86_64.iso" -boot d + +With CentOS guests, the install process fail sometimes, but sometimes it's able to install. However, on the yum update, it would freeze too. In one instance it froze while updating glibc, which made the guest unbootable. https://i.imgur.com/B3WhSDX.png + +The command line used was: + +qemu-system-x86_64 -nodefaults -m 2048 -M pc,usb=true -accel kvm -cpu host -smp cores=2,threads=2 -device qemu-xhci -drive id=centusb,if=none,file=centos.qcow2 -device usb-storage,id=centusb,drive=centusb -netdev user,id=n0 -device usb-tablet,id=usbtablet -device e1000,netdev=n0 -device usb-audio,id=usbaudio -device virtio-vga,virgl=true -display gtk -monitor vc -serial vc -cdrom "CentOS-7-livecd-GNOME-x86_64.iso" -bios /usr/share/ovmf/OVMF.fd + +With Xubuntu 18.04 guests, the system worked for many hours until the freeze happened. On this case it happened when opening Audacious. Fortunately, the logging services worked for some time, which allowed me to get a relevant message which can be seen at http://termbin.com/nuof . It repeated a few times, but then the logging stopped. https://i.imgur.com/2zckqj5.png shows the guest screen in the moment it froze. + +The command line used was: + +qemu-system-x86_64 -nodefaults -m 1024 -M pc,usb=true -accel kvm -cpu host -smp cores=2,threads=2 -device qemu-xhci -drive id=centusb,if=none,file=xubmini -device usb-storage,id=centusb,drive=centusb -netdev user,id=n0 -device usb-tablet,id=usbtablet -device e1000,netdev=n0 -device usb-audio,id=usbaudio -device qxl-vga,xres=1366,yres=768 -display gtk -monitor vc -serial vc + +I'm sorry for not having more detailed information but, even setting netconsole, openSUSE and CentOS guests were unable to print any information. + +Can you attach gdb to qemu when the guest hangs, then run "thread apply all bt"? + +I have run the openSUSE guest again, the output of the gdb command can be seen at https://paste.ubuntu.com/p/mCRMvkNWYq/ + +Hmm, nothing obvious in the stack trace. +Also doesn't reproduce here. +What qemu version is this? +If older than 3.0: Does it still happen for you with qemu 3.0? + +QEMU version I'm using now is v3.0.0-65-g1d746ee95d-dirty and has the problem, the first version I observed the problem was 2.11 from Ubuntu's repositories. + +The fact you are unable to reproduce the bug is unsurprising to me: this is not the first time I have a problem with QXL VGA and others are unable to reproduce. I don't understand why QXL fails so consistently here. + +Another QXL bug I reported: + +https://bugs.launchpad.net/ubuntu/bionic/+source/qemu/+bug/1755912 + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1793635 b/results/classifier/118/graphic/1793635 new file mode 100644 index 000000000..8acd23aed --- /dev/null +++ b/results/classifier/118/graphic/1793635 @@ -0,0 +1,43 @@ +graphic: 0.865 +performance: 0.859 +arm: 0.786 +device: 0.781 +ppc: 0.712 +semantic: 0.684 +architecture: 0.673 +boot: 0.660 +mistranslation: 0.658 +network: 0.603 +vnc: 0.595 +peripherals: 0.574 +user-level: 0.524 +register: 0.523 +socket: 0.520 +permissions: 0.477 +PID: 0.459 +debug: 0.403 +i386: 0.397 +risc-v: 0.397 +hypervisor: 0.378 +files: 0.377 +kernel: 0.371 +VMM: 0.353 +x86: 0.343 +TCG: 0.262 +assembly: 0.213 +virtual: 0.212 +KVM: 0.089 + +Using pflash with u-boot,when CONFIG_SYS_FLASH_USE_BUFFER_WRITE were defined,envirment args won't be able to save correctly + +Generated a u-boot image with qemu_arm_defconfig,did some modification to qemu-arm.h. +Before added "CONFIG_SYS_FLASH_USE_BUFFER_WRITE",call saveenv in u-boot command line can save the envirment but painful slow. + +after added it,seems the action took no time,but the data won't be saved correctly,reset the board to boot again(i'd waited a while to reset the board) ,the u-boot will tell you enviremnt checksum mismatch,using the default. + +How did you run QEMU? Is this still an issue with the latest version? + +No update from the reporter after 5 months, so closing the bug. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1794202 b/results/classifier/118/graphic/1794202 new file mode 100644 index 000000000..da6f8a667 --- /dev/null +++ b/results/classifier/118/graphic/1794202 @@ -0,0 +1,38 @@ +graphic: 0.952 +ppc: 0.931 +boot: 0.901 +device: 0.883 +network: 0.766 +mistranslation: 0.764 +semantic: 0.720 +files: 0.674 +socket: 0.658 +vnc: 0.633 +performance: 0.610 +register: 0.510 +PID: 0.463 +user-level: 0.462 +architecture: 0.457 +VMM: 0.439 +TCG: 0.401 +risc-v: 0.376 +arm: 0.356 +kernel: 0.342 +debug: 0.332 +x86: 0.330 +i386: 0.308 +peripherals: 0.254 +permissions: 0.249 +hypervisor: 0.241 +KVM: 0.229 +virtual: 0.222 +assembly: 0.200 + +Trying to install Mac OS X 10.5, it gives this error, "Mac OS X cannot be installed on your computer." + +When I try to install Mac OS X 10.5, it gives this error, "Mac OS X cannot be installed on your computer." Command ran in the command-line: "C:\Program Files\qemu\qemu-system-ppc" -L pc-bios -boot d -M mac99,via=pmu -m 512 -hda "C:\Users\*****\Downloads\macosx105\MacOSHDD.qcow2" -cdrom "C:\Users\*****\Downloads\macosx105\osx leopard install.iso" -netdev user,id=mynet0 -device sungem,netdev=mynet0 + + + +Fixed issue by switching boot from d to c. I found the solution by just seeing if it would work, and it does. + diff --git a/results/classifier/118/graphic/1795799 b/results/classifier/118/graphic/1795799 new file mode 100644 index 000000000..ddfa2ecac --- /dev/null +++ b/results/classifier/118/graphic/1795799 @@ -0,0 +1,89 @@ +graphic: 0.927 +device: 0.792 +i386: 0.777 +architecture: 0.711 +socket: 0.694 +x86: 0.642 +mistranslation: 0.639 +user-level: 0.589 +boot: 0.562 +semantic: 0.555 +PID: 0.547 +peripherals: 0.506 +hypervisor: 0.499 +kernel: 0.449 +register: 0.425 +performance: 0.390 +debug: 0.356 +vnc: 0.346 +ppc: 0.345 +arm: 0.344 +risc-v: 0.315 +files: 0.312 +VMM: 0.276 +permissions: 0.256 +virtual: 0.223 +TCG: 0.213 +network: 0.181 +assembly: 0.152 +KVM: 0.087 + +Cirrus video, graphical corruption, bad fonts + +The error +=== + +I started qemu by + +`shell +$ ./qemu-system-i386 -serial stdio -cdrom /dev/cdrom -vga cirrus +S1111111111S1111111111S1111111111S1111111111▒*n*n*n*n +` + +with the original suse7.0 cd 1 in the cdrom drive (I think https://archive.org/details/suse-7.0_release_i386 has the image). After some console output (that uses a vga framebuffer which seems to work fine) the suse installer is started. It is displayed mostly correct, but several text passages are completely garbled. + +I noticed the same type of corruption when trying to run an old XF86 SVGA Server on a SuSE 6.2 System using the `-vga cirrus` option. + +Therefore I think that the cirrus emulation might not work as intended any more. + +Qemu version +=== + +I used qemu-w64-setup-20180815.exe provided by https://qemu.weilnetz.de/w64/ + +./qemu-system-i386 -version +QEMU emulator version 3.0.0 (v3.0.0-11723-ge2ddcc5879-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +Hope you can fix it. + +Best regards! + + + +Here's what Suse62 does. + +I started this system by + +uli_r@DESKTOP-I4GHL3R /cygdrive/h/programme/qemu +$ ./qemu-system-i386 -serial stdio -hda suse62.ima -vga cirrus +WARNING: Image format was not specified for 'suse62.ima' 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. + +I configured X using the old sax (Suse Advanced X-Configurator) to use the SVGA server. Video memory is autodetected at only 64k, so I manually overwrote it to be 2048k, all other values I left as autodetected. I ordered it to start up in 1024x768@16bpp. + +Attached images show, what it does. + +It's the same host system with the same qemu version as above... + + + + +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.] + +FWIW, issue has been re-opened here: https://gitlab.com/qemu-project/qemu/-/issues/988 + diff --git a/results/classifier/118/graphic/1796 b/results/classifier/118/graphic/1796 new file mode 100644 index 000000000..931c2c568 --- /dev/null +++ b/results/classifier/118/graphic/1796 @@ -0,0 +1,46 @@ +graphic: 0.911 +device: 0.788 +mistranslation: 0.669 +semantic: 0.585 +files: 0.542 +assembly: 0.524 +PID: 0.524 +performance: 0.499 +network: 0.451 +hypervisor: 0.411 +i386: 0.401 +architecture: 0.377 +ppc: 0.364 +x86: 0.324 +VMM: 0.313 +socket: 0.300 +vnc: 0.291 +permissions: 0.274 +kernel: 0.272 +KVM: 0.268 +TCG: 0.262 +boot: 0.257 +debug: 0.227 +peripherals: 0.218 +user-level: 0.211 +register: 0.209 +arm: 0.200 +risc-v: 0.199 +virtual: 0.166 + +qemu-img does not accept backing image file path, only file name +Description of problem: +In `qemu-img create ... -b <backing_image> ... <snapshot_image>`, <backing_image> cannot be a file path, but must be a file name. <backing_image> and <snapshot_image> are forced to be in the same directory for the command to work. +Steps to reproduce: +``` +$ mkdir test +$ qemu-img create -f qcow2 test/a.img 1G +... +$ qemu-img create -f qcow2 -b test/a.img -F qcow2 test/a.img.snap +qemu-img: test/a.img.snap: Could not open 'test/test/a.img': No such file or directory +Could not open backing image. +$ qemu-img create -f qcow2 -b a.img -F qcow2 test/a.img.snap +... +$ ls test +a.img a.img.snap +``` diff --git a/results/classifier/118/graphic/1799919 b/results/classifier/118/graphic/1799919 new file mode 100644 index 000000000..4cab2df2a --- /dev/null +++ b/results/classifier/118/graphic/1799919 @@ -0,0 +1,55 @@ +graphic: 0.850 +architecture: 0.755 +device: 0.663 +performance: 0.648 +user-level: 0.641 +ppc: 0.581 +PID: 0.516 +permissions: 0.504 +semantic: 0.490 +peripherals: 0.481 +kernel: 0.479 +hypervisor: 0.466 +files: 0.463 +network: 0.459 +socket: 0.445 +mistranslation: 0.431 +register: 0.416 +virtual: 0.397 +vnc: 0.379 +debug: 0.377 +TCG: 0.357 +boot: 0.346 +risc-v: 0.335 +VMM: 0.324 +arm: 0.321 +assembly: 0.279 +i386: 0.245 +KVM: 0.222 +x86: 0.163 + +IDE HDD emulation random read/write errors + +I unfortunately can’t give more tracks other than how to reproduce the bug, especially that the bug occurs randomly. + +Basically, I’m trying to install DOS 6.22 on an emulated ISA machine, and it fails, DOS complaining about read or write error on drive C. Repeating the operation multiple time, I see it occurs at random stage, sometime even before it partitions the drive, sometime when it formats the drive, sometime when it copies the files from the floppy to the drive. + +To test it, unpack the attached archive and execute `./run` from the extracted directory. The archive contains three raw floppy images for installing DOS 6.22, and a Bourne Shell script which invokes QEmu. Just press enter at any installation stage, the bug may occurs at any stage. + +I tried with `cache=none` to be sure it’s not a cache issue, but its the same whatever the cache policy is. + +Version and environment: using QEmu 3.0 on Ubuntu 16.04 on a 32 bits DELL Inspiron 9400 (not an emulation, that’s my real laptop). + +For why I’m using QEmu for this: the installation proceeds with not error in VirtualBox, but I wanted to use QEmu to have a serial mouse which is not available with QEmu and to have finer control over the machine configuration ; VirtualBox although good, is more limited in that regard. + + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +I tried the repro case five times and each time it ran OK to the point of asking for floppy 2. So that suggests we probably fixed whatever it was... + + +Thanks, Peter! Looking at the bug description again and at the point in time when it happened, this was maybe a bug that we also saw with FreeDOS, caused by the CONFIG_ATA_DMA setting in Seabios, which had been fixed here: https://patchwork.kernel<email address hidden>/ +Anyway, let's mark this as fixed, if it happens again, then please re-open or file a new bug. + diff --git a/results/classifier/118/graphic/1800 b/results/classifier/118/graphic/1800 new file mode 100644 index 000000000..cef213ebf --- /dev/null +++ b/results/classifier/118/graphic/1800 @@ -0,0 +1,62 @@ +graphic: 0.997 +virtual: 0.982 +i386: 0.982 +x86: 0.970 +semantic: 0.736 +device: 0.580 +performance: 0.542 +ppc: 0.524 +TCG: 0.506 +architecture: 0.503 +PID: 0.433 +user-level: 0.404 +mistranslation: 0.390 +hypervisor: 0.390 +debug: 0.386 +vnc: 0.326 +socket: 0.305 +files: 0.289 +boot: 0.257 +kernel: 0.236 +network: 0.232 +permissions: 0.232 +KVM: 0.210 +register: 0.197 +VMM: 0.177 +arm: 0.170 +risc-v: 0.161 +peripherals: 0.115 +assembly: 0.108 + +8.1.0-rc1 Regression: donkey in qemu advent calender 03/2020 has graphical artifacts +Description of problem: +The game donkey shows graphical artifacts on playing. On changing the lane the car remains on its previous land as well. +A git bisect identified commit 592134617c98f37b8b39c6dd684e5a1832c071d2 as culprit +Steps to reproduce: +1. Download http://qemu-advent-calendar.org/2020/download/gw-basic.tar.xz +2. Start VM using command + ``` + qemu-system-i386 -m 16M -drive if=ide,format=qcow2,file=gwbasic.qcow2 + ``` +3. Wait for GW-Basic prompt and enter (see README): F3 - donkey - <ENTER> - F2 +4. Play to see graphical artifacts +Additional information: +``` +$ git bisect bad +592134617c98f37b8b39c6dd684e5a1832c071d2 is the first bad commit +commit 592134617c98f37b8b39c6dd684e5a1832c071d2 +Author: Richard Henderson +Date: Sun Oct 30 12:07:32 2022 +1100 + + accel/tcg: Reorg system mode store helpers + + Instead of trying to unify all operations on uint64_t, use + mmu_lookup() to perform the basic tlb hit and resolution. + Create individual functions to handle access by size. + + Reviewed-by: Peter Maydell <peter.maydell@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> + + accel/tcg/cputlb.c | 394 +++++++++++++++++++++++++---------------------------- + 1 file changed, 186 insertions(+), 208 deletions(-) +``` diff --git a/results/classifier/118/graphic/1803 b/results/classifier/118/graphic/1803 new file mode 100644 index 000000000..30f8c2c06 --- /dev/null +++ b/results/classifier/118/graphic/1803 @@ -0,0 +1,44 @@ +graphic: 0.990 +x86: 0.990 +architecture: 0.982 +TCG: 0.934 +ppc: 0.891 +device: 0.889 +boot: 0.876 +mistranslation: 0.829 +performance: 0.823 +semantic: 0.749 +register: 0.689 +user-level: 0.669 +permissions: 0.651 +files: 0.645 +PID: 0.626 +vnc: 0.586 +hypervisor: 0.569 +debug: 0.546 +risc-v: 0.534 +socket: 0.439 +peripherals: 0.414 +network: 0.407 +virtual: 0.388 +arm: 0.362 +VMM: 0.344 +KVM: 0.298 +kernel: 0.295 +i386: 0.274 +assembly: 0.210 + +8.x x86_64 system emulation/tcg regression (general protection fault) +Description of problem: +Running the ISO available at https://repo.chimera-linux.org/live/20230611/chimera-linux-x86_64-LIVE-20230611-gnome.iso with the above qemu command line, the graphical environment fails to come up. The system boots, and login prompt shows up; then graphical environment startup is attempted, with Wayland (you can tell as the login prompt cursor no longer blinks, being "frozen" for possibly up to a few minutes due to emulation cost). Then the graphical startup crashes (you can tell because the cursor starts blinking again) and an X11-based startup is attempted (you can tell by the X11 cross cursor) which however never fully comes up either. +Steps to reproduce: +1. Download the ISO and run with the command line above. +2. See the issue. +Additional information: +It is possible to then switch to tty2 (View->compatmonitor0, `sendkey ctrl-alt-f2`), log in as `root:chimera` or `anon:chimera` as the console prompt instructs, and type in `dmesg` (as `root`) or `doas dmesg` (as `anon`) and see that the `dmesg` contains a number of general protection faults, like this: + + + +The system used to work, but I am not sure which is the last version of QEMU where this worked, I believe 7.x. In 8.0.3 (likewise running in a Chimera environment, but it was also tested on Alpine, and I had somebody on Arch Linux test it with 8.0.2 just to rule out possible issues caused by a musl-based host environment) it crashes. It only appears to affect the `x86_64` guest architecture, as the other-architecture ISOs have graphical environment come up fine after some minutes (e.g. `ppc64le` with `qemu-system-ppc64 -M pseries-2.11,cap-htm=off -m 2048 -boot d -cdrom chimera-linux-ppc64le-LIVE-20230611-gnome.iso` works just fine). It also appears to only affect TCG emulation, as KVM likewise works fine (same command line, just `-enable-kvm` added). + +Apologies for a large testcase, but it seems to need specific graphical-adjacent services to reproduce. It should be consistently reproducible though. diff --git a/results/classifier/118/graphic/1805 b/results/classifier/118/graphic/1805 new file mode 100644 index 000000000..c01e95e22 --- /dev/null +++ b/results/classifier/118/graphic/1805 @@ -0,0 +1,96 @@ +graphic: 0.895 +semantic: 0.848 +register: 0.826 +PID: 0.796 +device: 0.786 +performance: 0.759 +x86: 0.757 +architecture: 0.751 +debug: 0.743 +socket: 0.720 +files: 0.717 +permissions: 0.700 +peripherals: 0.696 +VMM: 0.663 +network: 0.660 +ppc: 0.659 +user-level: 0.659 +TCG: 0.643 +kernel: 0.634 +mistranslation: 0.620 +boot: 0.609 +risc-v: 0.606 +arm: 0.602 +virtual: 0.601 +assembly: 0.546 +hypervisor: 0.520 +vnc: 0.507 +KVM: 0.479 +i386: 0.446 + +build-user-hexagon CI job is not actually testing hexagon +Description of problem: +Look at the output from the `build-user-hexagon` CI job and see what compiler meson reports it is using: + + https://gitlab.com/qemu-project/qemu/-/jobs/4790457871 + +``` +Project name: qemu +Project version: 8.0.91 +C compiler for the host machine: cc -m64 -mcx16 (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 20210110") +C linker for the host machine: cc -m64 -mcx16 ld.bfd 2.35.2 +Host machine cpu family: x86_64 +Host machine cpu: x86_64 +``` + +What is 'cc' resolving to ? + +``` +$ podman run -it registry.gitlab.com/qemu-project/qemu/qemu/debian-hexagon-cross cc -v | grep Target +Target: x86_64-linux-gnu +``` + +That is a x86_64 target native compiler, not a hexagon target cross compiler. + +The ``tests/docker/dockerfiles/debian-hexagon-cross.docker`` file installs the hexagon toolchain under ``/opt`` and adds the dir to ``$PATH`` with: + +``` +ENV PATH $PATH:${TOOLCHAIN_INSTALL}/${TOOLCHAIN_BASENAME}/x86_64-linux-gnu/bin +``` + +This toolchain just installs a `clang` binary, not ``cc`` + +So when ``configure`` runs it looks for ``cc`` first and finds the naitve x86_64 GCC install from the container, not the clang cross compiler + +It is also not possible to merely set ``CC=clang`` because meson will assume it is a native compiler and crash and burn when unable to run binaries + +``` +# CC=clang ./configure --target-list=x86_64-softmmu +Using './build' as the directory for build output +...snip... +Sphinx not found/usable, disabling docs. +Disabling PIE due to missing toolchain support +The Meson build system +Version: 1.2.0 +Source dir: /qemu +Build dir: /qemu/build +Build type: native build +Project name: qemu +Project version: 8.0.92 + +../meson.build:1:0: ERROR: Executables created by c compiler clang -m64 -mcx16 are not runnable. +``` + +AFAICT, the root problem here is that the hexagon container is not setup in the same way as the other cross compiler containers. + +We need the toolchain binaries to be named after the target triplet - ie not ``clang`` but ``hexagon-unknown-linux-musl-clang`` + +This used to be done but was thrown away when switching to a pre-built toolchain in b9052d36342c947b36447558ed0a0dd3fb3fb8f4 + +Then the container also needs to set the configure args for the cross target + +``` +ENV QEMU_CONFIGURE_OPTS --cross-prefix=hexagon-unknown-linux-musl- +``` + +AFAICT, this was never done, so even before switching to the pre-built toolchain, I think the `build-user-hexagon` CI job was running a native built not hexagon build. diff --git a/results/classifier/118/graphic/1806 b/results/classifier/118/graphic/1806 new file mode 100644 index 000000000..9a5541cd5 --- /dev/null +++ b/results/classifier/118/graphic/1806 @@ -0,0 +1,35 @@ +graphic: 0.979 +device: 0.938 +architecture: 0.894 +mistranslation: 0.849 +semantic: 0.847 +user-level: 0.845 +files: 0.844 +peripherals: 0.841 +boot: 0.816 +network: 0.815 +socket: 0.808 +vnc: 0.758 +debug: 0.738 +x86: 0.692 +performance: 0.650 +ppc: 0.647 +i386: 0.632 +PID: 0.623 +register: 0.617 +permissions: 0.593 +TCG: 0.593 +assembly: 0.560 +arm: 0.524 +risc-v: 0.472 +kernel: 0.450 +VMM: 0.401 +hypervisor: 0.389 +virtual: 0.349 +KVM: 0.023 + +Tests: YAMON binaries unavailable +Description of problem: +The [tests for MIPS](https://gitlab.com/qemu-project/qemu/-/blame/master/tests/avocado/machine_mips_malta.py#L127) download the YAMON firmware binaries, however that link does not exist anymore. It appears that it may have [moved to ](https://www.mips.com/develop/tools/boot-loaders/)mips.com (or maybe that's where it came from?), which states "To support existing users of these, and the QEMU project, YAMON is now available under the GPL License." However those links are also dead. I've not been able to find the referenced binaries or source anywhere. @philmd, do you happen to have a copy you can upload? Alternatively, I've found the 2.16 source [here](https://github.com/binsgit/mips-yamon). + +Another alternative would be to use U-boot, which is easy to get a hold of and would work for this test (just getting to a prompt, although I've had issues with it being able to access an IDE drive). I haven't found prebuilt binaries for MIPS and u-boot though. diff --git a/results/classifier/118/graphic/1807 b/results/classifier/118/graphic/1807 new file mode 100644 index 000000000..9b586b52b --- /dev/null +++ b/results/classifier/118/graphic/1807 @@ -0,0 +1,54 @@ +graphic: 0.860 +architecture: 0.767 +ppc: 0.677 +device: 0.661 +semantic: 0.653 +performance: 0.535 +PID: 0.512 +user-level: 0.427 +register: 0.361 +mistranslation: 0.353 +hypervisor: 0.341 +TCG: 0.332 +vnc: 0.331 +socket: 0.328 +files: 0.319 +debug: 0.297 +network: 0.286 +permissions: 0.266 +VMM: 0.254 +boot: 0.254 +risc-v: 0.241 +virtual: 0.232 +assembly: 0.203 +arm: 0.201 +x86: 0.196 +peripherals: 0.180 +kernel: 0.171 +i386: 0.157 +KVM: 0.063 + +sparc64 always segfaults doesn't work on Ubuntu 23.04 +Description of problem: +It segfaults when it tries to use 'printf' or 'puts' to print to the screen. +Steps to reproduce: +Do the following at the command line + +``` +$ sparc64-linux-gnu-g++ --version +sparc64-linux-gnu-g++ (Ubuntu 12.2.0-14ubuntu2) 12.2.0 +Copyright (C) 2022 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. +$ echo -e "#include <stdio.h> \n int main(void) { puts(\"Hello World\"); }" > test.cpp +$ sparc64-linux-gnu-g++ -o test test.cpp -static +$ qemu-sparc64-static --version +qemu-sparc64 version 7.2.0 (Debian 1:7.2+dfsg-5ubuntu2) +Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers +$ qemu-sparc64-static ./test +Segmentation fault (core dumped) +$ qemu-sparc-static ./test +qemu-sparc-static: ./test: Invalid ELF image for this architecture +$ qemu-sparc32plus-static ./test +qemu-sparc32plus-static: ./test: Invalid ELF image for this architecture +``` diff --git a/results/classifier/118/graphic/1810105 b/results/classifier/118/graphic/1810105 new file mode 100644 index 000000000..12f598baf --- /dev/null +++ b/results/classifier/118/graphic/1810105 @@ -0,0 +1,83 @@ +architecture: 0.981 +graphic: 0.962 +user-level: 0.959 +x86: 0.958 +device: 0.918 +peripherals: 0.900 +ppc: 0.890 +semantic: 0.882 +mistranslation: 0.882 +PID: 0.880 +performance: 0.868 +permissions: 0.853 +virtual: 0.835 +register: 0.804 +files: 0.743 +debug: 0.738 +network: 0.699 +TCG: 0.698 +VMM: 0.690 +socket: 0.689 +boot: 0.682 +kernel: 0.679 +vnc: 0.663 +i386: 0.654 +arm: 0.594 +risc-v: 0.574 +assembly: 0.570 +KVM: 0.569 +hypervisor: 0.565 + +Hint showing volume never disappears, blocking buttons to minimize, maximize and close + +When hovering the mouse over the volume indicator or changing its volume using the mouse wheel it shows the current volume set as a hint. For example: + +Volume 100% + +The problem is that the hint never disappears, not even clicking on it. On some occasions the hint can cover the minimize, maximize and close buttons, causing significant problems on using the desktop environment, as these three buttons won't be usable anymore with the hint over it. + +Where the hint appears it's no longer possible to interact with the screen. + +ProblemType: Bug +DistroRelease: Ubuntu 18.04 +Package: xfce4-pulseaudio-plugin 0.4.1-0ubuntu1 +ProcVersionSignature: Ubuntu 4.15.0-43.46-generic 4.15.18 +Uname: Linux 4.15.0-43-generic x86_64 +ApportVersion: 2.20.9-0ubuntu7.5 +Architecture: amd64 +CurrentDesktop: XFCE +Date: Sun Dec 30 17:09:23 2018 +InstallationDate: Installed on 2018-12-30 (0 days ago) +InstallationMedia: Xubuntu 18.04.2 LTS "Bionic Beaver" - Beta amd64 (20181230) +SourcePackage: xfce4-pulseaudio-plugin +UpgradeStatus: No upgrade log present (probably fresh install) + + + +I do not see this bug. Did you check if it affects another user account too? + +Yes, it happens with a new user. + +If I trigger this bug, returning to greeter with dm-tool switch-to-greeter, login with other user, use the other user account, log out, log in again to the first user, the hint is still visible. + +This bug has been reported on the Ubuntu ISO testing tracker. + +A list of all reports related to this bug can be found here: +http://iso.qa.ubuntu.com/qatracker/reports/bugs/1810105 + +It seems that this happen only if using the QEMU -device virtio-tablet-pci + +It seems all other input devices make the hint disappear as expected. + +I finally found a real computer on which this bug is present. + +The computer in question is a netbook manufactured by Positivo, the Mobo 5900, which is common on schools. It has a touchscreen with a pen which is compatible with evdev but that doesn't work with libinput. Its touchscreen is: + +Bus 004 Device 006: ID 22b9:0005 eTurboTouch Technology, Inc. + +The attached image not only shows the hint from the pulseaudio-plugin, but another one caused by pavucontrol. + +As a virtual keyboard is normally used because the netbook can be used as a tablet, the hints can make some keys impossible to use. + +If it's reproducible with real hardware, then it's definitely not a bug of QEMU ==> Removing QEMU from this bug ticket. + diff --git a/results/classifier/118/graphic/1813010 b/results/classifier/118/graphic/1813010 new file mode 100644 index 000000000..f4ab283d5 --- /dev/null +++ b/results/classifier/118/graphic/1813010 @@ -0,0 +1,98 @@ +graphic: 0.911 +semantic: 0.907 +user-level: 0.898 +permissions: 0.881 +vnc: 0.880 +register: 0.879 +peripherals: 0.877 +assembly: 0.871 +virtual: 0.870 +kernel: 0.863 +KVM: 0.859 +files: 0.858 +debug: 0.855 +mistranslation: 0.855 +TCG: 0.854 +hypervisor: 0.850 +risc-v: 0.847 +ppc: 0.843 +device: 0.840 +performance: 0.839 +VMM: 0.827 +PID: 0.825 +arm: 0.818 +architecture: 0.817 +socket: 0.781 +x86: 0.755 +network: 0.754 +boot: 0.747 +i386: 0.428 + +Parallel builds fail (make -j >=2) when using --extra-cflags "--save-temps" + +specs: +Host kernel: Linux 4.19.16-1-lts +Host type: x86_64 GNU/Linux +Host distro: Archlinux +Guest: we never get that far +QEMU commit: 9f33051abce238ab43a23125e237aac8b0931b88 + + +steps: +# fresh copy of the latest commit +> git clone https://git.qemu.org/git/qemu.git + +# separate build dir +> mkdir build +> cd build + +# sample configuration for riscv (this happens for other targets as well) +> ../qemu/configure --target-list=riscv64-softmmu --enable-debug --extra-cflags='-O0 -g3 -save-temps' --prefix=/install/riscv-qemu + +# this will fail (see attached log file) +> make -j 2 + + + +It seems the --save-temps is what breaks things for me, the following works: + + ../qemu.git/configure --target-list=riscv64-softmmu --enable-debug --extra-cflags="-O0 -g3" && make -j9 + +rm -rf and start again with: + + ../qemu.git/configure --target-list=riscv64-softmmu --enable-debug --extra-cflags="-O0 -g3 --save-temps" + +falls over with lines like: + + block/trace.h: In function ‘_nocheck__trace_nbd_co_request_fail’: +block/trace.h:3141:73: error: ‘_TRACE_NBD_CO_REQUEST_FAIL_DSTATE’ undeclared (first use in this function); did you mean ‘TRACE_NBD_CO_REQUEST_FAIL_BACKEND_DSTATE’? + if (trace_event_get_state(TRACE_NBD_CO_REQUEST_FAIL) && qemu_loglevel_mask(LOG_TRACE)) { + ^~~~~~~~~~~~~~~~~~~~ + TRACE_NBD_CO_REQUEST_FAIL_BACKEND_DSTATE + +which implies something getting in the way of making the trace files. + + +it seems like that "-save-temps" in "cflags" is the culprit. I removed it and it was possible to build with 8 instances: + +# removed "-save-temps" from the "cflags" +> ./qemu/configure --target-list=riscv64-softmmu --enable-debug --extra-cflags='-O0 -g3' --prefix=/install/riscv-qemu + +# build without any problem +> make -j 8 + +A workaround for this is to use "-save-temps=obj" which ensures the temps are dumped in the object directory. I suspect there is a clash somewhere between what save temps dumps and some of the files we generate for tracing. + +putting the temporary files in object dir works as well: -save-temps=obj + +# "-save-temps=obj" from the "cflags" +> ./qemu/configure --target-list=riscv64-softmmu --enable-debug --extra-cflags='-O0 -g3 -save-temps=obj' --prefix=/install/riscv-qemu + +# build again without any problem +> make -j 8 + +Hi; I'm going to close this bug because there's no way that QEMU's build process can handle being passed -save-temps via --extra-cflags, because this will cause GCC to use the same output files for multiple different source files, and they will clash. (Even with a non-parallel build, one compile is going to win, and the temp files for the first compile of the pair will just be overwritten and lost.) + +As you've discovered, the right way to do this is to use -save-temps=obj, which will correctly put the temporary files in different places for each generated object file, so they don't conflict with each other. + + diff --git a/results/classifier/118/graphic/1814 b/results/classifier/118/graphic/1814 new file mode 100644 index 000000000..de9e96dec --- /dev/null +++ b/results/classifier/118/graphic/1814 @@ -0,0 +1,46 @@ +graphic: 0.887 +performance: 0.827 +kernel: 0.799 +arm: 0.755 +hypervisor: 0.746 +device: 0.735 +architecture: 0.727 +ppc: 0.628 +peripherals: 0.626 +KVM: 0.622 +network: 0.619 +semantic: 0.605 +PID: 0.546 +mistranslation: 0.538 +debug: 0.536 +register: 0.502 +socket: 0.466 +vnc: 0.461 +risc-v: 0.433 +permissions: 0.398 +user-level: 0.368 +VMM: 0.356 +virtual: 0.353 +files: 0.316 +boot: 0.293 +TCG: 0.286 +assembly: 0.215 +i386: 0.123 +x86: 0.099 + +`-M none` breaks on ARM64 platforms with max IPA size < 40 +Description of problem: +QEMU fails to initialize the KVM type properly when `-M none` is used. On ARM64, the KVM type sets the IPA size. Without that setting, the kernel defaults to 40 bits. This fails on machines which cannot support that IPA size, such as Apple M1 machines. + +This presumably happens because `virt_machine_class_init()` in `hw/arm/virt.c` never gets called in that case, which means it doesn't initialize `mc->kvm_type` to the correct callback to do the IPA check. + +Since the max IPA size is a property of the host CPU and must be queried properly for things to work at all, this logic should be invoked unconditionally for all machines, even `none`. + +This is breaking libvirt on Apple M1/M2 systems, since it uses `-M none,accel=kvm` for its KVM test, and when it fails it considers KVM support unavailable. See: https://gitlab.com/libvirt/libvirt/-/issues/365 +Steps to reproduce: +On any ARM64 machine: + +1. strace -e ioctl qemu-system-aarch64 -M none,accel=kvm 2>&1 | grep -C1 CREATE_VM +2. strace -e ioctl qemu-system-aarch64 -M virt,accel=kvm 2>&1 | grep -C1 CREATE_VM + +Observe that the first command line does not issue a `KVM_CAP_ARM_VM_IPA_SIZE` and does not set the machine type argument to `KVM_CREATE_VM`, while the second one does. On machines with <40 bit max IPA, the first invocation would fail to initialize KVM. diff --git a/results/classifier/118/graphic/1814343 b/results/classifier/118/graphic/1814343 new file mode 100644 index 000000000..9a4f761ef --- /dev/null +++ b/results/classifier/118/graphic/1814343 @@ -0,0 +1,66 @@ +graphic: 0.881 +kernel: 0.869 +performance: 0.799 +device: 0.786 +architecture: 0.766 +mistranslation: 0.752 +semantic: 0.721 +risc-v: 0.701 +user-level: 0.698 +virtual: 0.607 +register: 0.593 +x86: 0.589 +PID: 0.575 +files: 0.569 +hypervisor: 0.557 +debug: 0.555 +ppc: 0.539 +VMM: 0.527 +i386: 0.526 +peripherals: 0.522 +socket: 0.511 +arm: 0.500 +network: 0.481 +permissions: 0.468 +vnc: 0.468 +boot: 0.445 +KVM: 0.418 +TCG: 0.411 +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/118/graphic/1816 b/results/classifier/118/graphic/1816 new file mode 100644 index 000000000..0ce8f1ba1 --- /dev/null +++ b/results/classifier/118/graphic/1816 @@ -0,0 +1,104 @@ +graphic: 0.820 +permissions: 0.762 +semantic: 0.701 +debug: 0.694 +performance: 0.686 +peripherals: 0.666 +arm: 0.656 +PID: 0.654 +device: 0.649 +risc-v: 0.647 +register: 0.630 +ppc: 0.627 +files: 0.616 +assembly: 0.600 +user-level: 0.598 +architecture: 0.587 +boot: 0.584 +VMM: 0.562 +virtual: 0.519 +socket: 0.515 +kernel: 0.511 +vnc: 0.457 +KVM: 0.453 +TCG: 0.422 +hypervisor: 0.386 +x86: 0.377 +mistranslation: 0.371 +network: 0.335 +i386: 0.222 + +Memory size limitation under podman on Apple silicon +Description of problem: +We are using latest MacOS (Ventura) on M2 Ultra with 128Gb RAM (Mac Studio) to run our product Linux aarch64 builds in podman containers. This is cheaper than buying ARM server hardware, and we are not able to use cloud services. + +The issue arises when we try to use the available RAM for the underlying QEMU machine. There seems to be a memory limit which looks like it is in QEMU not podman machine, since that is more of a wrapper in this process. + +The use case is to init a Fedora Linux VM by QEMU which provides a Linux kernel. That kernel is then used to run podman containers. + +When we set the memory limit to 64513Mb the podman machine (VM) start fails with "Error: HV_BAD_ARGUMENT". If we reduce the memory limit to "64512" it works as expected. + +This is an example of how to reproduce: + +` +macstudio:~ build $ podman machine init --cpus="18" --memory="64513" podman-machine-default +Extracting compressed file +Image resized. +Machine init complete +To start your machine run: + +podman machine start + +macstudio:~ build $ podman machine start +Starting machine "podman-machine-default" +Waiting for VM ... +Error: qemu exited unexpectedly with exit code -1, stderr: qemu-system-aarch64: Error: HV_BAD_ARGUMENT + +macstudio:~ build $ podman machine rm --force +macstudio:~ build $ podman machine init --cpus="18" --memory="64512" podman-machine-default +Extracting compressed file +Image resized. +Machine init complete +To start your machine run: + +podman machine start + +macstudio:~ build $ podman machine start +Starting machine "podman-machine-default" +Waiting for VM ... +Mounting volume... /Users:/Users +Mounting volume... /private:/private +Mounting volume... /var/folders:/var/folders + +This machine is currently configured in rootless mode. If your containers +require root permissions (e.g. ports < 1024), or if you run into compatibility +issues with non-podman clients, you can switch using the following command: + +podman machine set --rootful + +API forwarding listening on: /Users/build_ci/.local/share/containers/podman/machine/qemu/podman.sock + +The system helper service is not installed; the default Docker API socket +address can't be used by podman. If you would like to install it run the +following commands: + +sudo /opt/homebrew/Cellar/podman/4.6.0/bin/podman-mac-helper install +podman machine stop; podman machine start + +You can still connect Docker API clients by setting DOCKER_HOST using the +following command in your terminal session: + +export DOCKER_HOST='unix:///Users/build/.local/share/containers/podman/machine/qemu/podman.sock' + +Machine "podman-machine-default" started successfully +macstudio:~ build $ podman machine ls +NAME VM TYPE CREATED LAST UP CPUS MEMORY DISK SIZE +podman-machine-default* qemu About a minute ago Currently running 18 63GiB 100GiB + +` +Steps to reproduce: +1. Initialise the VM with a RAM limit of 64513Mb, then start it. +2. +3. +Additional information: +Feel free to ask for more information. Unfortunately, these machines are our production platform, so further testing will not have a rapid turn around. We are open to taking a machine out of production for testing, it just needs scheduling. diff --git a/results/classifier/118/graphic/1818 b/results/classifier/118/graphic/1818 new file mode 100644 index 000000000..e498de7bd --- /dev/null +++ b/results/classifier/118/graphic/1818 @@ -0,0 +1,50 @@ +graphic: 0.978 +device: 0.914 +hypervisor: 0.912 +performance: 0.858 +semantic: 0.835 +architecture: 0.785 +mistranslation: 0.729 +user-level: 0.713 +ppc: 0.700 +PID: 0.685 +files: 0.610 +arm: 0.595 +assembly: 0.555 +debug: 0.555 +virtual: 0.532 +permissions: 0.522 +register: 0.516 +boot: 0.508 +vnc: 0.480 +socket: 0.477 +peripherals: 0.456 +x86: 0.410 +network: 0.405 +kernel: 0.400 +TCG: 0.356 +VMM: 0.333 +risc-v: 0.281 +KVM: 0.099 +i386: 0.009 + +whpx does not work with hyper-v enabled +Description of problem: +I am experiencing issues with the WHPX (Windows Hypervisor Platform Accelerator) hardware acceleration in QEMU on my Windows 10 22h2 system. When I run QEMU with the `-accel whpx` option, I encounter the following problems: + +2. I receive the error message "WHPX: No accelerator found, hr=00000000" followed by "failed to initialize whpx: No space left on device." +Steps to reproduce: +1. Enable the Hyper-V feature on Windows. +2. Install the latest QEMU version +3. Run the QEMU command with the `-accel whpx` option. +Additional information: +- my cpu : intel i7 6500U +- ram : 8 gigabytes +- gpu : intel hd 520 +- drive : C: -> 200 gigabytes, D: -> 1to (c: 109 used, d: 732 used) +- emulated drive -> 50 gigabytes (500mb used) + + + + +(in french sorry) diff --git a/results/classifier/118/graphic/1819908 b/results/classifier/118/graphic/1819908 new file mode 100644 index 000000000..64b199715 --- /dev/null +++ b/results/classifier/118/graphic/1819908 @@ -0,0 +1,57 @@ +graphic: 0.956 +kernel: 0.707 +semantic: 0.682 +performance: 0.680 +device: 0.652 +virtual: 0.604 +user-level: 0.592 +KVM: 0.573 +hypervisor: 0.550 +mistranslation: 0.533 +x86: 0.432 +architecture: 0.394 +i386: 0.390 +ppc: 0.389 +PID: 0.360 +permissions: 0.317 +network: 0.303 +register: 0.290 +socket: 0.257 +debug: 0.254 +risc-v: 0.231 +peripherals: 0.230 +VMM: 0.226 +arm: 0.205 +assembly: 0.201 +vnc: 0.181 +TCG: 0.172 +files: 0.134 +boot: 0.097 + +slight screen corruption when maximizing window + +Host: Ubuntu disco +qemu-kvm: 1:3.1+dfsg-2ubuntu2 +libvirt: 5.0.0-1ubuntu2 + + +Guest: ubuntu bionic +guest is using cirrus video, with the extra modules kernel package installed and the cirrus kernel module loaded + +A non-maximized terminal window works just fine. As an example, I run "lsmod". It fills the screen, which then scrolls a bit. + +The moment I maximize that window, though, the rendering breaks. I can see the commands I type, but not their output. See attached video. + + + +lsmod run on a non-maximized window. All looks good. + +continuing from the previous screenshot, all I did here was to click the maximize button. We can already see some bad rendering on the top right corner. + +Here, with the maximized window, I typed several commands again: lsmod, clear, clear. If you look carefully, you can see the clear at the bottom, then at the top again, and nothing changes. All I can see are the characters I type, but not the command's output or effect. The screen doesn't clear, and the list of modules produced by "lsmod" doesn't appear. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1822798 b/results/classifier/118/graphic/1822798 new file mode 100644 index 000000000..a751ae99c --- /dev/null +++ b/results/classifier/118/graphic/1822798 @@ -0,0 +1,55 @@ +graphic: 0.843 +semantic: 0.715 +device: 0.703 +performance: 0.592 +mistranslation: 0.585 +user-level: 0.561 +architecture: 0.550 +PID: 0.548 +x86: 0.538 +network: 0.529 +hypervisor: 0.509 +files: 0.505 +VMM: 0.498 +ppc: 0.489 +permissions: 0.479 +virtual: 0.466 +KVM: 0.458 +i386: 0.456 +vnc: 0.453 +risc-v: 0.444 +kernel: 0.439 +socket: 0.417 +peripherals: 0.388 +TCG: 0.377 +register: 0.349 +debug: 0.335 +boot: 0.298 +assembly: 0.249 +arm: 0.239 + +The hover of " Full list of releases " is not effective even not visible. + +The hover effect of "Full list of releases " on QEMU website that is https://www.qemu.org/ is not visible and hence effective so made it the issue on git hub and even committed it. + +The hover button color is changed so that is it effectively visible. line number 307 + +.button:hover + { + + background: #8f1b1b; + text-decoration: none; + } + + +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/48 + + +Ticket now got moved to the qemu-web part: + + https://gitlab.com/qemu-project/qemu-web/-/issues/1 + diff --git a/results/classifier/118/graphic/1826393 b/results/classifier/118/graphic/1826393 new file mode 100644 index 000000000..740597e0e --- /dev/null +++ b/results/classifier/118/graphic/1826393 @@ -0,0 +1,742 @@ +graphic: 0.822 +register: 0.808 +user-level: 0.784 +performance: 0.773 +mistranslation: 0.747 +peripherals: 0.739 +semantic: 0.729 +risc-v: 0.723 +permissions: 0.709 +architecture: 0.698 +virtual: 0.695 +device: 0.693 +debug: 0.666 +boot: 0.655 +arm: 0.637 +assembly: 0.617 +ppc: 0.596 +network: 0.596 +hypervisor: 0.582 +TCG: 0.576 +PID: 0.573 +x86: 0.539 +kernel: 0.532 +socket: 0.530 +VMM: 0.508 +files: 0.500 +vnc: 0.488 +KVM: 0.485 +i386: 0.390 + +QEMU 3.1.0 stuck waiting for 800ms (5 times slower) in pre-bios phase + +Yesterday I have upgraded my laptop from Ubuntu 18.10 to 19.04 and that way got newer QEMU 3.1.0 along vs QEMU 2.12.0 before. I have noticed that everytime I start QEMU to run OSv, QEMU seems to hand noticably longer (~1 second) before showing SeaBIOS output. I have tried all kind of combinations to get rid of that pause and nothing helped. + +Here is my start command: +time qemu-system-x86_64 -m 256M -smp 1 -nographic -nodefaults \ + -device virtio-blk-pci,id=blk0,bootindex=0,drive=hd0,scsi=off \ + -drive file=usr.img,if=none,id=hd0,cache=none,aio=thre\ + -enable-kvm \ + -cpu host,+x2apic -chardev stdio,mux=on,id=stdio,signal=off \ + -mon chardev=stdio,mode=readline -device isa-serial,chardev=stdio + +It looks like qemu process starts, waits almost a second for something and then print SeaBIOS splashscreen and continues boot: + +--> waits here +SeaBIOS (version 1.12.0-1) +Booting from Hard Disk..OSv v0.53.0-6-gc8395118 + disk read (real mode): 27.25ms, (+27.25ms) + uncompress lzloader.elf: 46.22ms, (+18.97ms) + TLS initialization: 46.79ms, (+0.57ms) + .init functions: 47.82ms, (+1.03ms) + SMP launched: 48.08ms, (+0.26ms) + VFS initialized: 49.25ms, (+1.17ms) + Network initialized: 49.48ms, (+0.24ms) + pvpanic done: 49.57ms, (+0.08ms) + pci enumerated: 52.42ms, (+2.85ms) + drivers probe: 52.42ms, (+0.00ms) + drivers loaded: 55.33ms, (+2.90ms) + ROFS mounted: 56.37ms, (+1.04ms) + Total time: 56.37ms, (+0.00ms) +Found optarg +dev etc hello libenviron.so libvdso.so proc tmp tools usr + +real 0m0.935s +user 0m0.426s +sys 0m0.490s + +With version 2.12.0 I used to see real below 200ms. So it seems qemu slowed down 5 times. + +I ran strace -tt against it and I have noticed a pause here: +... +07:31:41.848579 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +07:31:41.848604 futex(0x55c4a2ff6308, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 +07:31:41.848649 ioctl(10, KVM_SET_PIT2, 0x7ffdd272d1f0) = 0 +07:31:41.848674 ioctl(9, KVM_CHECK_EXTENSION, KVM_CAP_KVMCLOCK_CTRL) = 1 +07:31:41.848699 ioctl(10, KVM_SET_CLOCK, 0x7ffdd272d230) = 0 +07:31:41.848724 futex(0x55c4a49a9a9c, FUTEX_WAKE_PRIVATE, 2147483647) = 1 +07:31:41.848747 getpid() = 5162 +07:31:41.848769 tgkill(5162, 5166, SIGUSR1) = 0 +07:31:41.848791 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +07:31:41.848814 futex(0x55c4a49a9a98, FUTEX_WAKE_PRIVATE, 2147483647) = 1 +07:31:41.848837 getpid() = 5162 +07:31:41.848858 tgkill(5162, 5166, SIGUSR1) = 0 +07:31:41.848889 write(8, "\1\0\0\0\0\0\0\0", 8) = 8 +07:31:41.848919 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +07:31:41.848943 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +{fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=0}, NULL, 8) = 1 ([{fd=8, revents=POLLIN}], left {tv_sec=0, tv_nsec=0 +}) +07:31:41.849003 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) +07:31:41.849031 read(8, "\5\0\0\0\0\0\0\0", 16) = 8 +07:31:41.849064 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +07:31:41.849086 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +{fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=984624000}, NULL, 8) = 1 ([{fd=7, revents=POLLIN}], left {tv_sec=0, t +v_nsec=190532609}) + +--> waits for almost 800ms + +07:31:42.643272 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = 0 +07:31:42.643522 read(7, "\1\0\0\0\0\0\0\0", 512) = 8 +07:31:42.643625 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +07:31:42.643646 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +{fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=190066000}, NULL, 8) = 2 ([{fd=4, revents=POLLIN}, {fd=8, revents=POL +LIN}], left {tv_sec=0, tv_nsec=189909632}) +07:31:42.643836 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) +07:31:42.643859 read(8, "\2\0\0\0\0\0\0\0", 16) = 8 +07:31:42.643880 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 + +... + +when I run same command using qemu 3.0.5 that I still happen to have on the same machine that I built directly from source I see total boot time at around 200ms. It seems like a regression. + +On Thu, Apr 25, 2019 at 11:37:02AM -0000, Waldemar Kozaczuk wrote: +> Public bug reported: +> +> Yesterday I have upgraded my laptop from Ubuntu 18.10 to 19.04 and that +> way got newer QEMU 3.1.0 along vs QEMU 2.12.0 before. I have noticed +> that everytime I start QEMU to run OSv, QEMU seems to hand noticably +> longer (~1 second) before showing SeaBIOS output. I have tried all kind +> of combinations to get rid of that pause and nothing helped. +> +> Here is my start command: +> time qemu-system-x86_64 -m 256M -smp 1 -nographic -nodefaults \ +> -device virtio-blk-pci,id=blk0,bootindex=0,drive=hd0,scsi=off \ +> -drive file=usr.img,if=none,id=hd0,cache=none,aio=thre\ +> -enable-kvm \ +> -cpu host,+x2apic -chardev stdio,mux=on,id=stdio,signal=off \ +> -mon chardev=stdio,mode=readline -device isa-serial,chardev=stdio +> +> It looks like qemu process starts, waits almost a second for something +> and then print SeaBIOS splashscreen and continues boot: +> +> --> waits here +> SeaBIOS (version 1.12.0-1) +> Booting from Hard Disk..OSv v0.53.0-6-gc8395118 +> disk read (real mode): 27.25ms, (+27.25ms) +> uncompress lzloader.elf: 46.22ms, (+18.97ms) +> TLS initialization: 46.79ms, (+0.57ms) +> .init functions: 47.82ms, (+1.03ms) +> SMP launched: 48.08ms, (+0.26ms) +> VFS initialized: 49.25ms, (+1.17ms) +> Network initialized: 49.48ms, (+0.24ms) +> pvpanic done: 49.57ms, (+0.08ms) +> pci enumerated: 52.42ms, (+2.85ms) +> drivers probe: 52.42ms, (+0.00ms) +> drivers loaded: 55.33ms, (+2.90ms) +> ROFS mounted: 56.37ms, (+1.04ms) +> Total time: 56.37ms, (+0.00ms) +> Found optarg +> dev etc hello libenviron.so libvdso.so proc tmp tools usr +> +> real 0m0.935s +> user 0m0.426s +> sys 0m0.490s +> +> With version 2.12.0 I used to see real below 200ms. So it seems qemu +> slowed down 5 times. +> +> I ran strace -tt against it and I have noticed a pause here: +> ... +> 07:31:41.848579 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +> 07:31:41.848604 futex(0x55c4a2ff6308, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 +> 07:31:41.848649 ioctl(10, KVM_SET_PIT2, 0x7ffdd272d1f0) = 0 +> 07:31:41.848674 ioctl(9, KVM_CHECK_EXTENSION, KVM_CAP_KVMCLOCK_CTRL) = 1 +> 07:31:41.848699 ioctl(10, KVM_SET_CLOCK, 0x7ffdd272d230) = 0 +> 07:31:41.848724 futex(0x55c4a49a9a9c, FUTEX_WAKE_PRIVATE, 2147483647) = 1 +> 07:31:41.848747 getpid() = 5162 +> 07:31:41.848769 tgkill(5162, 5166, SIGUSR1) = 0 +> 07:31:41.848791 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +> 07:31:41.848814 futex(0x55c4a49a9a98, FUTEX_WAKE_PRIVATE, 2147483647) = 1 +> 07:31:41.848837 getpid() = 5162 +> 07:31:41.848858 tgkill(5162, 5166, SIGUSR1) = 0 +> 07:31:41.848889 write(8, "\1\0\0\0\0\0\0\0", 8) = 8 +> 07:31:41.848919 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +> 07:31:41.848943 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +> {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=0}, NULL, 8) = 1 ([{fd=8, revents=POLLIN}], left {tv_sec=0, tv_nsec=0 +> }) +> 07:31:41.849003 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) +> 07:31:41.849031 read(8, "\5\0\0\0\0\0\0\0", 16) = 8 +> 07:31:41.849064 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +> 07:31:41.849086 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +> {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=984624000}, NULL, 8) = 1 ([{fd=7, revents=POLLIN}], left {tv_sec=0, t +> v_nsec=190532609}) +> +> --> waits for almost 800ms +> +> 07:31:42.643272 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = 0 +> 07:31:42.643522 read(7, "\1\0\0\0\0\0\0\0", 512) = 8 +> 07:31:42.643625 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +> 07:31:42.643646 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +> {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=190066000}, NULL, 8) = 2 ([{fd=4, revents=POLLIN}, {fd=8, revents=POL +> LIN}], left {tv_sec=0, tv_nsec=189909632}) +> 07:31:42.643836 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) +> 07:31:42.643859 read(8, "\2\0\0\0\0\0\0\0", 16) = 8 +> 07:31:42.643880 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +> +> ... +> +> when I run same command using qemu 3.0.5 that I still happen to have on +> the same machine that I built directly from source I see total boot time +> at around 200ms. It seems like a regression. + +Please try building QEMU 4.0.0 from source: + + https://download.qemu.org/qemu-4.0.0.tar.xz + +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1826393 +> +> Title: +> QEMU 3.1.0 stuck waiting for 800ms (5 times slower) in pre-bios phase +> +> Status in QEMU: +> New +> +> Bug description: +> Yesterday I have upgraded my laptop from Ubuntu 18.10 to 19.04 and +> that way got newer QEMU 3.1.0 along vs QEMU 2.12.0 before. I have +> noticed that everytime I start QEMU to run OSv, QEMU seems to hand +> noticably longer (~1 second) before showing SeaBIOS output. I have +> tried all kind of combinations to get rid of that pause and nothing +> helped. +> +> Here is my start command: +> time qemu-system-x86_64 -m 256M -smp 1 -nographic -nodefaults \ +> -device virtio-blk-pci,id=blk0,bootindex=0,drive=hd0,scsi=off \ +> -drive file=usr.img,if=none,id=hd0,cache=none,aio=thre\ +> -enable-kvm \ +> -cpu host,+x2apic -chardev stdio,mux=on,id=stdio,signal=off \ +> -mon chardev=stdio,mode=readline -device isa-serial,chardev=stdio +> +> It looks like qemu process starts, waits almost a second for something +> and then print SeaBIOS splashscreen and continues boot: +> +> --> waits here +> SeaBIOS (version 1.12.0-1) +> Booting from Hard Disk..OSv v0.53.0-6-gc8395118 +> disk read (real mode): 27.25ms, (+27.25ms) +> uncompress lzloader.elf: 46.22ms, (+18.97ms) +> TLS initialization: 46.79ms, (+0.57ms) +> .init functions: 47.82ms, (+1.03ms) +> SMP launched: 48.08ms, (+0.26ms) +> VFS initialized: 49.25ms, (+1.17ms) +> Network initialized: 49.48ms, (+0.24ms) +> pvpanic done: 49.57ms, (+0.08ms) +> pci enumerated: 52.42ms, (+2.85ms) +> drivers probe: 52.42ms, (+0.00ms) +> drivers loaded: 55.33ms, (+2.90ms) +> ROFS mounted: 56.37ms, (+1.04ms) +> Total time: 56.37ms, (+0.00ms) +> Found optarg +> dev etc hello libenviron.so libvdso.so proc tmp tools usr +> +> real 0m0.935s +> user 0m0.426s +> sys 0m0.490s +> +> With version 2.12.0 I used to see real below 200ms. So it seems qemu +> slowed down 5 times. +> +> I ran strace -tt against it and I have noticed a pause here: +> ... +> 07:31:41.848579 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +> 07:31:41.848604 futex(0x55c4a2ff6308, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 +> 07:31:41.848649 ioctl(10, KVM_SET_PIT2, 0x7ffdd272d1f0) = 0 +> 07:31:41.848674 ioctl(9, KVM_CHECK_EXTENSION, KVM_CAP_KVMCLOCK_CTRL) = 1 +> 07:31:41.848699 ioctl(10, KVM_SET_CLOCK, 0x7ffdd272d230) = 0 +> 07:31:41.848724 futex(0x55c4a49a9a9c, FUTEX_WAKE_PRIVATE, 2147483647) = 1 +> 07:31:41.848747 getpid() = 5162 +> 07:31:41.848769 tgkill(5162, 5166, SIGUSR1) = 0 +> 07:31:41.848791 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +> 07:31:41.848814 futex(0x55c4a49a9a98, FUTEX_WAKE_PRIVATE, 2147483647) = 1 +> 07:31:41.848837 getpid() = 5162 +> 07:31:41.848858 tgkill(5162, 5166, SIGUSR1) = 0 +> 07:31:41.848889 write(8, "\1\0\0\0\0\0\0\0", 8) = 8 +> 07:31:41.848919 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +> 07:31:41.848943 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +> {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=0}, NULL, 8) = 1 ([{fd=8, revents=POLLIN}], left {tv_sec=0, tv_nsec=0 +> }) +> 07:31:41.849003 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) +> 07:31:41.849031 read(8, "\5\0\0\0\0\0\0\0", 16) = 8 +> 07:31:41.849064 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +> 07:31:41.849086 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +> {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=984624000}, NULL, 8) = 1 ([{fd=7, revents=POLLIN}], left {tv_sec=0, t +> v_nsec=190532609}) +> +> --> waits for almost 800ms +> +> 07:31:42.643272 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = 0 +> 07:31:42.643522 read(7, "\1\0\0\0\0\0\0\0", 512) = 8 +> 07:31:42.643625 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +> 07:31:42.643646 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +> {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=190066000}, NULL, 8) = 2 ([{fd=4, revents=POLLIN}, {fd=8, revents=POL +> LIN}], left {tv_sec=0, tv_nsec=189909632}) +> 07:31:42.643836 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) +> 07:31:42.643859 read(8, "\2\0\0\0\0\0\0\0", 16) = 8 +> 07:31:42.643880 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +> +> ... +> +> when I run same command using qemu 3.0.5 that I still happen to have +> on the same machine that I built directly from source I see total boot +> time at around 200ms. It seems like a regression. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1826393/+subscriptions +> + + +On Mon, Apr 29, 2019 at 11:47:33AM -0400, Stefan Hajnoczi wrote: +> On Thu, Apr 25, 2019 at 11:37:02AM -0000, Waldemar Kozaczuk wrote: +> +> Please try building QEMU 4.0.0 from source: +> +> https://download.qemu.org/qemu-4.0.0.tar.xz +> + +It seems that is related to an issue with some TPM timeouts found in +SeaBIOS 1.12.0: +https://<email address hidden>/msg575060.html + +As Stefan suggested the new QEMU 4.0.0 should not have this issue since +it is shipped with SeaBIOS 1.12.1 (where the fix is applied). + +If you want to use QEMU 3.1.0 with the new SeaBIOS, you can download it +and use the '-bios' parameter: + $ wget https://github.com/qemu/qemu/blob/v4.0.0/pc-bios/bios-256k.bin + $ qemu-system-x86_64 -bios /path/to/bios-256k.bin ... + + + + +I tried with the bios https://github.com/qemu/qemu/blob/v4.0.0/pc-bios/bios-256k.bin and it failed like so: +``` +qemu: could not load PC BIOS 'bios-256k.bin' +qemu failed. +``` + +Have not had chance to try with QEMU 4 yet. + + +Oh sorry, you're using the 'pc' machine, so please try this bios: https://github.com/qemu/qemu/blob/v4.0.0/pc-bios/bios.bin + + + +The last bios indeed helped. It knows runs under 200ms. + +Do you anticipate doing minor release of 3.1.0 with updated bios to address +this issue? Or users are expected to upgrade to QEMU 4.0.0? + +Regards, +Waldek + +On Thu, May 2, 2019 at 4:05 AM Stefano Garzarella < +<email address hidden>> wrote: + +> Oh sorry, you're using the 'pc' machine, so please try this bios: +> https://github.com/qemu/qemu/blob/v4.0.0/pc-bios/bios.bin +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1826393 +> +> Title: +> QEMU 3.1.0 stuck waiting for 800ms (5 times slower) in pre-bios phase +> +> Status in QEMU: +> New +> +> Bug description: +> Yesterday I have upgraded my laptop from Ubuntu 18.10 to 19.04 and +> that way got newer QEMU 3.1.0 along vs QEMU 2.12.0 before. I have +> noticed that everytime I start QEMU to run OSv, QEMU seems to hand +> noticably longer (~1 second) before showing SeaBIOS output. I have +> tried all kind of combinations to get rid of that pause and nothing +> helped. +> +> Here is my start command: +> time qemu-system-x86_64 -m 256M -smp 1 -nographic -nodefaults \ +> -device virtio-blk-pci,id=blk0,bootindex=0,drive=hd0,scsi=off \ +> -drive file=usr.img,if=none,id=hd0,cache=none,aio=thre\ +> -enable-kvm \ +> -cpu host,+x2apic -chardev stdio,mux=on,id=stdio,signal=off \ +> -mon chardev=stdio,mode=readline -device isa-serial,chardev=stdio +> +> It looks like qemu process starts, waits almost a second for something +> and then print SeaBIOS splashscreen and continues boot: +> +> --> waits here +> SeaBIOS (version 1.12.0-1) +> Booting from Hard Disk..OSv v0.53.0-6-gc8395118 +> disk read (real mode): 27.25ms, (+27.25ms) +> uncompress lzloader.elf: 46.22ms, (+18.97ms) +> TLS initialization: 46.79ms, (+0.57ms) +> .init functions: 47.82ms, (+1.03ms) +> SMP launched: 48.08ms, (+0.26ms) +> VFS initialized: 49.25ms, (+1.17ms) +> Network initialized: 49.48ms, (+0.24ms) +> pvpanic done: 49.57ms, (+0.08ms) +> pci enumerated: 52.42ms, (+2.85ms) +> drivers probe: 52.42ms, (+0.00ms) +> drivers loaded: 55.33ms, (+2.90ms) +> ROFS mounted: 56.37ms, (+1.04ms) +> Total time: 56.37ms, (+0.00ms) +> Found optarg +> dev etc hello libenviron.so libvdso.so proc tmp tools usr +> +> real 0m0.935s +> user 0m0.426s +> sys 0m0.490s +> +> With version 2.12.0 I used to see real below 200ms. So it seems qemu +> slowed down 5 times. +> +> I ran strace -tt against it and I have noticed a pause here: +> ... +> 07:31:41.848579 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +> 07:31:41.848604 futex(0x55c4a2ff6308, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 +> 07:31:41.848649 ioctl(10, KVM_SET_PIT2, 0x7ffdd272d1f0) = 0 +> 07:31:41.848674 ioctl(9, KVM_CHECK_EXTENSION, KVM_CAP_KVMCLOCK_CTRL) = 1 +> 07:31:41.848699 ioctl(10, KVM_SET_CLOCK, 0x7ffdd272d230) = 0 +> 07:31:41.848724 futex(0x55c4a49a9a9c, FUTEX_WAKE_PRIVATE, 2147483647) = 1 +> 07:31:41.848747 getpid() = 5162 +> 07:31:41.848769 tgkill(5162, 5166, SIGUSR1) = 0 +> 07:31:41.848791 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +> 07:31:41.848814 futex(0x55c4a49a9a98, FUTEX_WAKE_PRIVATE, 2147483647) = 1 +> 07:31:41.848837 getpid() = 5162 +> 07:31:41.848858 tgkill(5162, 5166, SIGUSR1) = 0 +> 07:31:41.848889 write(8, "\1\0\0\0\0\0\0\0", 8) = 8 +> 07:31:41.848919 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +> 07:31:41.848943 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, +> {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +> {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=0}, NULL, 8) = 1 ([{fd=8, +> revents=POLLIN}], left {tv_sec=0, tv_nsec=0 +> }) +> 07:31:41.849003 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 +> EAGAIN (Resource temporarily unavailable) +> 07:31:41.849031 read(8, "\5\0\0\0\0\0\0\0", 16) = 8 +> 07:31:41.849064 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +> 07:31:41.849086 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, +> {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +> {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=984624000}, NULL, 8) = 1 +> ([{fd=7, revents=POLLIN}], left {tv_sec=0, t +> v_nsec=190532609}) +> +> --> waits for almost 800ms +> +> 07:31:42.643272 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = 0 +> 07:31:42.643522 read(7, "\1\0\0\0\0\0\0\0", 512) = 8 +> 07:31:42.643625 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +> 07:31:42.643646 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, +> {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +> {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=190066000}, NULL, 8) = 2 +> ([{fd=4, revents=POLLIN}, {fd=8, revents=POL +> LIN}], left {tv_sec=0, tv_nsec=189909632}) +> 07:31:42.643836 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 +> EAGAIN (Resource temporarily unavailable) +> 07:31:42.643859 read(8, "\2\0\0\0\0\0\0\0", 16) = 8 +> 07:31:42.643880 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +> +> ... +> +> when I run same command using qemu 3.0.5 that I still happen to have +> on the same machine that I built directly from source I see total boot +> time at around 200ms. It seems like a regression. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1826393/+subscriptions +> + + +On Mon, May 06, 2019 at 05:40:05PM -0000, Waldemar Kozaczuk wrote: +> The last bios indeed helped. It knows runs under 200ms. +> +> Do you anticipate doing minor release of 3.1.0 with updated bios to address +> this issue? Or users are expected to upgrade to QEMU 4.0.0? + +CCing Gerd + +I'm not sure we will release SeaBIOS 1.12.1 with a minor release of QEMU +3.1.0, so upgrading to QEMU 4.0 should be the way to address this issue. + +Regards, +Stefano + +> +> Regards, +> Waldek +> +> On Thu, May 2, 2019 at 4:05 AM Stefano Garzarella < +> <email address hidden>> wrote: +> +> > Oh sorry, you're using the 'pc' machine, so please try this bios: +> > https://github.com/qemu/qemu/blob/v4.0.0/pc-bios/bios.bin +> > +> > -- +> > You received this bug notification because you are subscribed to the bug +> > report. +> > https://bugs.launchpad.net/bugs/1826393 +> > +> > Title: +> > QEMU 3.1.0 stuck waiting for 800ms (5 times slower) in pre-bios phase +> > +> > Status in QEMU: +> > New +> > +> > Bug description: +> > Yesterday I have upgraded my laptop from Ubuntu 18.10 to 19.04 and +> > that way got newer QEMU 3.1.0 along vs QEMU 2.12.0 before. I have +> > noticed that everytime I start QEMU to run OSv, QEMU seems to hand +> > noticably longer (~1 second) before showing SeaBIOS output. I have +> > tried all kind of combinations to get rid of that pause and nothing +> > helped. +> > +> > Here is my start command: +> > time qemu-system-x86_64 -m 256M -smp 1 -nographic -nodefaults \ +> > -device virtio-blk-pci,id=blk0,bootindex=0,drive=hd0,scsi=off \ +> > -drive file=usr.img,if=none,id=hd0,cache=none,aio=thre\ +> > -enable-kvm \ +> > -cpu host,+x2apic -chardev stdio,mux=on,id=stdio,signal=off \ +> > -mon chardev=stdio,mode=readline -device isa-serial,chardev=stdio +> > +> > It looks like qemu process starts, waits almost a second for something +> > and then print SeaBIOS splashscreen and continues boot: +> > +> > --> waits here +> > SeaBIOS (version 1.12.0-1) +> > Booting from Hard Disk..OSv v0.53.0-6-gc8395118 +> > disk read (real mode): 27.25ms, (+27.25ms) +> > uncompress lzloader.elf: 46.22ms, (+18.97ms) +> > TLS initialization: 46.79ms, (+0.57ms) +> > .init functions: 47.82ms, (+1.03ms) +> > SMP launched: 48.08ms, (+0.26ms) +> > VFS initialized: 49.25ms, (+1.17ms) +> > Network initialized: 49.48ms, (+0.24ms) +> > pvpanic done: 49.57ms, (+0.08ms) +> > pci enumerated: 52.42ms, (+2.85ms) +> > drivers probe: 52.42ms, (+0.00ms) +> > drivers loaded: 55.33ms, (+2.90ms) +> > ROFS mounted: 56.37ms, (+1.04ms) +> > Total time: 56.37ms, (+0.00ms) +> > Found optarg +> > dev etc hello libenviron.so libvdso.so proc tmp tools usr +> > +> > real 0m0.935s +> > user 0m0.426s +> > sys 0m0.490s +> > +> > With version 2.12.0 I used to see real below 200ms. So it seems qemu +> > slowed down 5 times. +> > +> > I ran strace -tt against it and I have noticed a pause here: +> > ... +> > 07:31:41.848579 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +> > 07:31:41.848604 futex(0x55c4a2ff6308, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 +> > 07:31:41.848649 ioctl(10, KVM_SET_PIT2, 0x7ffdd272d1f0) = 0 +> > 07:31:41.848674 ioctl(9, KVM_CHECK_EXTENSION, KVM_CAP_KVMCLOCK_CTRL) = 1 +> > 07:31:41.848699 ioctl(10, KVM_SET_CLOCK, 0x7ffdd272d230) = 0 +> > 07:31:41.848724 futex(0x55c4a49a9a9c, FUTEX_WAKE_PRIVATE, 2147483647) = 1 +> > 07:31:41.848747 getpid() = 5162 +> > 07:31:41.848769 tgkill(5162, 5166, SIGUSR1) = 0 +> > 07:31:41.848791 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +> > 07:31:41.848814 futex(0x55c4a49a9a98, FUTEX_WAKE_PRIVATE, 2147483647) = 1 +> > 07:31:41.848837 getpid() = 5162 +> > 07:31:41.848858 tgkill(5162, 5166, SIGUSR1) = 0 +> > 07:31:41.848889 write(8, "\1\0\0\0\0\0\0\0", 8) = 8 +> > 07:31:41.848919 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +> > 07:31:41.848943 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, +> > {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +> > {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=0}, NULL, 8) = 1 ([{fd=8, +> > revents=POLLIN}], left {tv_sec=0, tv_nsec=0 +> > }) +> > 07:31:41.849003 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 +> > EAGAIN (Resource temporarily unavailable) +> > 07:31:41.849031 read(8, "\5\0\0\0\0\0\0\0", 16) = 8 +> > 07:31:41.849064 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +> > 07:31:41.849086 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, +> > {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +> > {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=984624000}, NULL, 8) = 1 +> > ([{fd=7, revents=POLLIN}], left {tv_sec=0, t +> > v_nsec=190532609}) +> > +> > --> waits for almost 800ms +> > +> > 07:31:42.643272 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = 0 +> > 07:31:42.643522 read(7, "\1\0\0\0\0\0\0\0", 512) = 8 +> > 07:31:42.643625 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +> > 07:31:42.643646 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, +> > {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +> > {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=190066000}, NULL, 8) = 2 +> > ([{fd=4, revents=POLLIN}, {fd=8, revents=POL +> > LIN}], left {tv_sec=0, tv_nsec=189909632}) +> > 07:31:42.643836 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 +> > EAGAIN (Resource temporarily unavailable) +> > 07:31:42.643859 read(8, "\2\0\0\0\0\0\0\0", 16) = 8 +> > 07:31:42.643880 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +> > +> > ... +> > +> > when I run same command using qemu 3.0.5 that I still happen to have +> > on the same machine that I built directly from source I see total boot +> > time at around 200ms. It seems like a regression. +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/1826393/+subscriptions +> > +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1826393 +> +> Title: +> QEMU 3.1.0 stuck waiting for 800ms (5 times slower) in pre-bios phase +> +> Status in QEMU: +> New +> +> Bug description: +> Yesterday I have upgraded my laptop from Ubuntu 18.10 to 19.04 and +> that way got newer QEMU 3.1.0 along vs QEMU 2.12.0 before. I have +> noticed that everytime I start QEMU to run OSv, QEMU seems to hand +> noticably longer (~1 second) before showing SeaBIOS output. I have +> tried all kind of combinations to get rid of that pause and nothing +> helped. +> +> Here is my start command: +> time qemu-system-x86_64 -m 256M -smp 1 -nographic -nodefaults \ +> -device virtio-blk-pci,id=blk0,bootindex=0,drive=hd0,scsi=off \ +> -drive file=usr.img,if=none,id=hd0,cache=none,aio=thre\ +> -enable-kvm \ +> -cpu host,+x2apic -chardev stdio,mux=on,id=stdio,signal=off \ +> -mon chardev=stdio,mode=readline -device isa-serial,chardev=stdio +> +> It looks like qemu process starts, waits almost a second for something +> and then print SeaBIOS splashscreen and continues boot: +> +> --> waits here +> SeaBIOS (version 1.12.0-1) +> Booting from Hard Disk..OSv v0.53.0-6-gc8395118 +> disk read (real mode): 27.25ms, (+27.25ms) +> uncompress lzloader.elf: 46.22ms, (+18.97ms) +> TLS initialization: 46.79ms, (+0.57ms) +> .init functions: 47.82ms, (+1.03ms) +> SMP launched: 48.08ms, (+0.26ms) +> VFS initialized: 49.25ms, (+1.17ms) +> Network initialized: 49.48ms, (+0.24ms) +> pvpanic done: 49.57ms, (+0.08ms) +> pci enumerated: 52.42ms, (+2.85ms) +> drivers probe: 52.42ms, (+0.00ms) +> drivers loaded: 55.33ms, (+2.90ms) +> ROFS mounted: 56.37ms, (+1.04ms) +> Total time: 56.37ms, (+0.00ms) +> Found optarg +> dev etc hello libenviron.so libvdso.so proc tmp tools usr +> +> real 0m0.935s +> user 0m0.426s +> sys 0m0.490s +> +> With version 2.12.0 I used to see real below 200ms. So it seems qemu +> slowed down 5 times. +> +> I ran strace -tt against it and I have noticed a pause here: +> ... +> 07:31:41.848579 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +> 07:31:41.848604 futex(0x55c4a2ff6308, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 +> 07:31:41.848649 ioctl(10, KVM_SET_PIT2, 0x7ffdd272d1f0) = 0 +> 07:31:41.848674 ioctl(9, KVM_CHECK_EXTENSION, KVM_CAP_KVMCLOCK_CTRL) = 1 +> 07:31:41.848699 ioctl(10, KVM_SET_CLOCK, 0x7ffdd272d230) = 0 +> 07:31:41.848724 futex(0x55c4a49a9a9c, FUTEX_WAKE_PRIVATE, 2147483647) = 1 +> 07:31:41.848747 getpid() = 5162 +> 07:31:41.848769 tgkill(5162, 5166, SIGUSR1) = 0 +> 07:31:41.848791 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +> 07:31:41.848814 futex(0x55c4a49a9a98, FUTEX_WAKE_PRIVATE, 2147483647) = 1 +> 07:31:41.848837 getpid() = 5162 +> 07:31:41.848858 tgkill(5162, 5166, SIGUSR1) = 0 +> 07:31:41.848889 write(8, "\1\0\0\0\0\0\0\0", 8) = 8 +> 07:31:41.848919 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +> 07:31:41.848943 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +> {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=0}, NULL, 8) = 1 ([{fd=8, revents=POLLIN}], left {tv_sec=0, tv_nsec=0 +> }) +> 07:31:41.849003 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) +> 07:31:41.849031 read(8, "\5\0\0\0\0\0\0\0", 16) = 8 +> 07:31:41.849064 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 0 +> 07:31:41.849086 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +> {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=984624000}, NULL, 8) = 1 ([{fd=7, revents=POLLIN}], left {tv_sec=0, t +> v_nsec=190532609}) +> +> --> waits for almost 800ms +> +> 07:31:42.643272 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = 0 +> 07:31:42.643522 read(7, "\1\0\0\0\0\0\0\0", 512) = 8 +> 07:31:42.643625 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +> 07:31:42.643646 ppoll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, +> {fd=8, events=POLLIN}], 5, {tv_sec=0, tv_nsec=190066000}, NULL, 8) = 2 ([{fd=4, revents=POLLIN}, {fd=8, revents=POL +> LIN}], left {tv_sec=0, tv_nsec=189909632}) +> 07:31:42.643836 futex(0x55c4a2fd34c0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) +> 07:31:42.643859 read(8, "\2\0\0\0\0\0\0\0", 16) = 8 +> 07:31:42.643880 futex(0x55c4a2fd34c0, FUTEX_WAKE_PRIVATE, 1) = 1 +> +> ... +> +> when I run same command using qemu 3.0.5 that I still happen to have +> on the same machine that I built directly from source I see total boot +> time at around 200ms. It seems like a regression. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1826393/+subscriptions + +-- + +Stefano Garzarella +Software Engineer @ Red Hat + + +On Tue, May 14, 2019 at 10:04:14AM +0200, Stefano Garzarella wrote: +> On Mon, May 06, 2019 at 05:40:05PM -0000, Waldemar Kozaczuk wrote: +> > The last bios indeed helped. It knows runs under 200ms. +> > +> > Do you anticipate doing minor release of 3.1.0 with updated bios to address +> > this issue? Or users are expected to upgrade to QEMU 4.0.0? +> +> CCing Gerd +> +> I'm not sure we will release SeaBIOS 1.12.1 with a minor release of QEMU +> 3.1.0, so upgrading to QEMU 4.0 should be the way to address this issue. + +I think with the 4.0 release 3.1 is EOL and there will be no more 3.1.x +stable releases ... + +cheers, + Gerd + + + diff --git a/results/classifier/118/graphic/1826599 b/results/classifier/118/graphic/1826599 new file mode 100644 index 000000000..63363f1ab --- /dev/null +++ b/results/classifier/118/graphic/1826599 @@ -0,0 +1,49 @@ +graphic: 0.942 +x86: 0.939 +architecture: 0.932 +device: 0.929 +performance: 0.927 +boot: 0.919 +socket: 0.899 +PID: 0.876 +network: 0.857 +files: 0.849 +peripherals: 0.832 +ppc: 0.826 +vnc: 0.816 +hypervisor: 0.812 +kernel: 0.796 +register: 0.734 +debug: 0.726 +permissions: 0.704 +risc-v: 0.702 +VMM: 0.634 +i386: 0.614 +semantic: 0.613 +arm: 0.563 +TCG: 0.539 +virtual: 0.537 +user-level: 0.383 +mistranslation: 0.299 +assembly: 0.273 +KVM: 0.104 + +qemu crashes with HV_ERROR with any guest when using HVF on macos + +qemu reliably crashes (after some unknown amount of time) for any guest I've run on macos with HVF acceleration. + +I'm currently running Haiku. After booting and running normally for a few minutes, it abruptly crashes and shows this error on stdout (I'm including the command line arguments): + ++ ISO=haiku-release-anyboot.iso ++ ACCEL='-accel hvf -machine type=q35,accel=hvf' ++ MEM='-m 1G' ++ SMP='-c 2' ++ NET='-device virtio-net,netdev=vmnic -netdev user,id=vmnic' ++ IMG_CD='-cdrom haiku-release-anyboot.iso' ++ IMG_HDD='-device virtio-scsi-pci,id=scsi -drive if=none,id=vd0,file=haiku.img,format=raw -device scsi-hd,drive=vd0' ++ DISPLAY='-usb -device usb-tablet' ++ qemu-system-x86_64 -accel hvf -machine type=q35,accel=hvf -usb -device usb-tablet -m 1G -device virtio-net,netdev=vmnic -netdev user,id=vmnic -device virtio-scsi-pci,id=scsi -drive if=none,id=vd0,file=haiku.img,format=raw -device scsi-hd,drive=vd0 +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] +qemu-system-x86_64: Error: HV_ERROR +./qemu-boot.sh: line 19: 67497 Abort trap: 6 qemu-system-x86_64 $ACCEL $CPU $EFI $DISPLAY $MEM $NET $IMG_HDD + diff --git a/results/classifier/118/graphic/1827 b/results/classifier/118/graphic/1827 new file mode 100644 index 000000000..a8830e523 --- /dev/null +++ b/results/classifier/118/graphic/1827 @@ -0,0 +1,31 @@ +graphic: 0.828 +device: 0.718 +ppc: 0.707 +performance: 0.447 +PID: 0.402 +permissions: 0.355 +semantic: 0.355 +peripherals: 0.344 +boot: 0.329 +TCG: 0.297 +debug: 0.220 +risc-v: 0.212 +mistranslation: 0.171 +architecture: 0.101 +network: 0.099 +arm: 0.096 +register: 0.077 +i386: 0.076 +vnc: 0.072 +x86: 0.067 +hypervisor: 0.059 +user-level: 0.043 +assembly: 0.036 +virtual: 0.034 +VMM: 0.034 +kernel: 0.029 +socket: 0.029 +KVM: 0.011 +files: 0.010 + +Turn DPRINTF macro use into tracepoints diff --git a/results/classifier/118/graphic/1827005 b/results/classifier/118/graphic/1827005 new file mode 100644 index 000000000..86f4225f3 --- /dev/null +++ b/results/classifier/118/graphic/1827005 @@ -0,0 +1,63 @@ +graphic: 0.889 +boot: 0.857 +x86: 0.764 +mistranslation: 0.730 +device: 0.675 +semantic: 0.622 +TCG: 0.557 +user-level: 0.530 +performance: 0.522 +register: 0.482 +permissions: 0.481 +PID: 0.469 +architecture: 0.443 +ppc: 0.439 +hypervisor: 0.406 +files: 0.398 +vnc: 0.388 +risc-v: 0.388 +kernel: 0.367 +virtual: 0.361 +socket: 0.361 +network: 0.358 +debug: 0.352 +arm: 0.347 +VMM: 0.297 +i386: 0.292 +peripherals: 0.247 +assembly: 0.232 +KVM: 0.178 + +hvf: ubuntu iso boot menu issue + +With hvf acceleration on macOS, ubuntu server installation ISO boot language menu shows fractured images. + +To reproduce the issue: +./x86_64-softmmu/qemu-system-x86_64 -m 800 -accel hvf -cdrom ~/ubuntu-16.04.4-server-amd64.iso + +Control: +./x86_64-softmmu/qemu-system-x86_64 -m 800 -accel tcg -cdrom ~/ubuntu-16.04.4-server-amd64.iso + +Host: macOS Mojave 10.14.3 +Guest: Ubuntu Server 16.04.4 ISO +QEMU: version 3.1.94 (v4.0.0-rc4) + + + + + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1827871 b/results/classifier/118/graphic/1827871 new file mode 100644 index 000000000..dffe9e7f9 --- /dev/null +++ b/results/classifier/118/graphic/1827871 @@ -0,0 +1,78 @@ +graphic: 0.923 +permissions: 0.922 +mistranslation: 0.917 +semantic: 0.915 +architecture: 0.907 +debug: 0.903 +performance: 0.896 +device: 0.894 +user-level: 0.890 +risc-v: 0.890 +assembly: 0.890 +register: 0.884 +peripherals: 0.878 +virtual: 0.877 +boot: 0.870 +TCG: 0.861 +hypervisor: 0.861 +arm: 0.857 +ppc: 0.836 +PID: 0.836 +files: 0.831 +vnc: 0.829 +VMM: 0.794 +kernel: 0.784 +socket: 0.770 +x86: 0.750 +KVM: 0.744 +network: 0.712 +i386: 0.618 + +Race condition when rebooting with the TCG backend + +Reporting this as present in QEMU 3.1.0, although I don't see any commit in current git master (a6ae23831b05a11880b40f7d58e332c45a6b04f7) that would suggest this issue is fixed. + + $ uname -a + Linux boole 4.19.0-4-686-pae #1 SMP Debian 4.19.28-2 (2019-03-15) i686 GNU/Linux + $ qemu -version + QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7) + Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + +Here's an excerpt from the code which handles reboot requests in SeaBIOS 1.12, located in src/fw/shadow.c: + + // Request a QEMU system reset. Do the reset in this function as + // the BIOS code was overwritten above and not all BIOS + // functionality may be available. + + // Attempt PCI style reset + outb(0x02, PORT_PCI_REBOOT); + outb(0x06, PORT_PCI_REBOOT); + + // Next try triple faulting the CPU to force a reset + asm volatile("int3"); + +This compiles to the following: + + (qemu) x/10i 0xf1993 + 0x000f1993: b0 02 movb $2, %al + 0x000f1995: ee outb %al, %dx + 0x000f1996: b0 06 movb $6, %al + 0x000f1998: ee outb %al, %dx + 0x000f1999: cc int3 + 0x000f199a: 80 3d 0d 53 0f 00 08 cmpb $8, 0xf530d + 0x000f19a1: 75 52 jne 0xf19f5 + 0x000f19a3: a1 10 53 0f 00 movl 0xf5310, %eax + 0x000f19a8: 8b 15 14 53 0f 00 movl 0xf5314, %edx + 0x000f19ae: 89 c3 movl %eax, %ebx + +Now, with the TCG backend, upon reaching the second outb instruction, the thread executing JIT-ed opcodes invokes qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET). This signals another thread to reset the guest CPU registers to their initial state. However, the execution thread is *not* stopped, which means it will keep executing already-translated instructions in the TCG buffer. In particular, the bootstrap value of the EIP register will be overwritten. On my machine, this usually results in the guest CPU finding itself in real mode, CS base 0xffff0000, EIP 0x0000199e, which in real mode disassembles to this: + + (qemu) xp/1i 0xf199e + 0x000f199e: 0f 00 08 strw 0(%bx, %si) + +This instruction triggers a #UD exception, and given that SeaBIOS handles #UD by immediately returning, it manifests as the guest locking up with 100% CPU usage every other reboot. + +Never mind, 0ec7e6779fc830e5b4e6a448d75317fafcf69477 fixed this. + +This can be closed. + diff --git a/results/classifier/118/graphic/1828272 b/results/classifier/118/graphic/1828272 new file mode 100644 index 000000000..f7b18cdf7 --- /dev/null +++ b/results/classifier/118/graphic/1828272 @@ -0,0 +1,57 @@ +graphic: 0.919 +x86: 0.854 +device: 0.767 +boot: 0.735 +architecture: 0.664 +ppc: 0.578 +performance: 0.571 +semantic: 0.535 +KVM: 0.529 +files: 0.457 +permissions: 0.452 +kernel: 0.449 +i386: 0.441 +arm: 0.420 +user-level: 0.354 +PID: 0.352 +mistranslation: 0.294 +risc-v: 0.285 +network: 0.284 +register: 0.279 +virtual: 0.274 +hypervisor: 0.270 +socket: 0.264 +VMM: 0.248 +vnc: 0.232 +debug: 0.215 +TCG: 0.209 +assembly: 0.144 +peripherals: 0.124 + +4.0 breaks keyboard autorepeat in guests with xserver + +Description: +In a linux/bsd guest within X, pressing and holding a key for a short time causes an endless repeat of that key in the guest. The release of the key gets ignored. +Example 1: pressing and holding 'a' for a few seconds results in typing of 'aaaaaaaaaaaa...' endlessly. +Example 2: pressing and holding 'Backspace' for a few seconds results in deleting all your previously typed text. + +It doesn't happen within a VT in the guest. It also doesn't happen with guests that run windows, reactos or haiku for example. + +The problem goes away, when disabling xorgs autorepeat function via "xset -r" in the host. +Normally, this setting should not have any effect on the guest, since it has it's own autorepeat setting. So there is some conflict here. + +Steps to reproduce: +Start any linux/bsd guest system with xserver, open a terminal, press and hold a key for a short time: Look how it gets typed endlessly (Try a few times if it doesn't happen immediately). +The easiest way is to run a linux live cd, like this (Link to example iso :http://download.grml.org/grml64-full_2018.12.iso) +$ qemu-system-x86_64 -enable-kvm -m 512 -boot d -cdrom grml64-full_2018.12.iso + + +Qemu version info: +QEMU emulator version 4.0.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +Adding Gerd to the CC, since this is possibly caused by recent work to keyboard state tracking code. + +Fix has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5fff13f245cddd3bc26 + diff --git a/results/classifier/118/graphic/1830 b/results/classifier/118/graphic/1830 new file mode 100644 index 000000000..adcd4a71b --- /dev/null +++ b/results/classifier/118/graphic/1830 @@ -0,0 +1,56 @@ +architecture: 0.966 +graphic: 0.963 +debug: 0.961 +PID: 0.918 +performance: 0.760 +device: 0.704 +semantic: 0.700 +ppc: 0.690 +arm: 0.663 +permissions: 0.547 +files: 0.537 +peripherals: 0.534 +user-level: 0.524 +register: 0.514 +mistranslation: 0.452 +kernel: 0.404 +socket: 0.369 +hypervisor: 0.358 +vnc: 0.302 +boot: 0.284 +assembly: 0.254 +virtual: 0.233 +TCG: 0.224 +VMM: 0.219 +network: 0.217 +risc-v: 0.180 +KVM: 0.045 +x86: 0.022 +i386: 0.011 + +command hangs in CentOS 7 arm64 container with Ubuntu 22 amd64 host +Description of problem: +The command hangs in the container, taking over the CPU: + +``` +$ docker run -it centos:7 +[root@42e655bf3d60 /]# LD_DEBUG=all /lib64/ld-2.17.so --list /usr/bin/true & +[1] 74 +[root@42e655bf3d60 /]# 74: file=/usr/bin/true [0]; generating link map + +[root@42e655bf3d60 /]# ps -e -o pid,ppid,etime,time,state,args + PID PPID ELAPSED TIME S COMMAND + 1 0 34:59 00:00:00 S /usr/libexec/qemu-binfmt/aarch64-binfmt-P /bin/bash /bin/bash + 74 1 03:16 00:03:13 R /usr/libexec/qemu-binfmt/aarch64-binfmt-P /lib64/ld-2.17.so /lib64/ld-2.17.so + 80 1 4-19:34:01 00:00:00 R ps -e -o pid,ppid,etime,time,state,args +[root@42e655bf3d60 /]# +``` +Steps to reproduce: +1. Start container +2. Run `/lib64/ld-2.17.so --list /usr/bin/true` +Additional information: +1. The problem is not observed in an Ubuntu 20.04 host system performing the same scenario. +2. My team build environment has amd64 native architecture hardware. I ran a similar scenario on an AWS arm64 native machine (QEMU is not needed) and the command works fine in the container. +3. My team builds several Linux images daily - about a dozen amd64 and eight arm64. This is the only image that's causing us this problem. +4. I built trace-cmd but when I tried to start a trace it told me `No events enabled with kvm`. +5. I built qemu-8.1.0-rc3 and saw the same behavior but I don't think `/usr/libexec/qemu-binfmt/aarch64-binfmt-P` was replaced with a new version so I don't think the old version was used for my container. diff --git a/results/classifier/118/graphic/1833 b/results/classifier/118/graphic/1833 new file mode 100644 index 000000000..245391034 --- /dev/null +++ b/results/classifier/118/graphic/1833 @@ -0,0 +1,114 @@ +graphic: 0.848 +semantic: 0.810 +peripherals: 0.773 +permissions: 0.719 +debug: 0.677 +register: 0.655 +hypervisor: 0.646 +architecture: 0.646 +device: 0.643 +virtual: 0.642 +user-level: 0.623 +risc-v: 0.606 +performance: 0.595 +ppc: 0.595 +arm: 0.592 +TCG: 0.579 +assembly: 0.577 +PID: 0.558 +socket: 0.524 +vnc: 0.518 +kernel: 0.517 +VMM: 0.487 +mistranslation: 0.463 +KVM: 0.460 +network: 0.431 +boot: 0.429 +files: 0.429 +x86: 0.424 +i386: 0.421 + +ARM64 SME ST1Q incorrectly stores 9 bytes (rather than 16) per 128-bit element +Description of problem: +QEMU incorrectly stores 9 bytes instead of 16 per 128-bit element in the ST1Q SME instruction (https://developer.arm.com/documentation/ddi0602/2022-06/SME-Instructions/ST1Q--Contiguous-store-of-quadwords-from-128-bit-element-ZA-tile-slice-). It copies the first byte of the upper 64-bits, then lower the 64-bits. + +This seems to be a simple issue; I tracked it down to: +https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/tcg/sme_helper.c?ref_type=heads#L382 + +Updating that `+ 1` to a `+ 8` fixes the problem. +Steps to reproduce: +```c +#include <stdio.h> +#include <stdint.h> +#include <string.h> + +void st1q_sme_copy_test(uint8_t* src, uint8_t* dest) { + asm volatile( + "smstart sm\n" + "smstart za\n" + "ptrue p0.b\n" + "mov x12, xzr\n" + "ld1q {za0h.q[w12, 0]}, p0/z, %0\n" + "st1q {za0h.q[w12, 0]}, p0, %1\n" + "smstop za\n" + "smstop sm\n" : : "m"(*src), "m"(*dest) : "w12", "p0"); +} + +void print_first_128(uint8_t* data) { + putchar('['); + for (int i = 0; i < 16; i++) { + printf("%02d", data[i]); + if (i != 15) + printf(", "); + } + printf("]\n"); +} + +int main() { + _Alignas(16) uint8_t dest[512] = { }; + _Alignas(16) uint8_t src[512] = { }; + for (int i = 0; i < sizeof(src); i++) + src[i] = i; + puts("Before"); + printf(" src: "); + print_first_128(src); + printf("dest: "); + print_first_128(dest); + st1q_sme_copy_test(src, dest); + puts("\nAfter "); + printf(" src: "); + print_first_128(src); + printf("dest: "); + print_first_128(dest); +} +``` + +Compile with (requires at least clang ~14, tested with clang 16):<br/> +`clang ./qemu_repro.c -march=armv9-a+sme+sve -o ./qemu_repro` + +Run with:<br/> +`qemu-aarch64 -cpu max,sme=on ./qemu_repro` + +It's expected just to copy from `src` to `dest` and output: +``` +Before + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] + +After + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +``` + +But currently outputs: +``` +Before + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] + +After + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 08, 09, 10, 11, 12, 13, 14, 15, 00, 00, 00, 00, 00, 00, 00] +``` +Additional information: +N/A diff --git a/results/classifier/118/graphic/1835 b/results/classifier/118/graphic/1835 new file mode 100644 index 000000000..3e550f958 --- /dev/null +++ b/results/classifier/118/graphic/1835 @@ -0,0 +1,48 @@ +graphic: 0.978 +network: 0.923 +performance: 0.903 +x86: 0.893 +device: 0.838 +ppc: 0.824 +architecture: 0.820 +peripherals: 0.801 +boot: 0.760 +PID: 0.750 +semantic: 0.743 +debug: 0.728 +vnc: 0.707 +hypervisor: 0.693 +permissions: 0.683 +assembly: 0.670 +socket: 0.658 +virtual: 0.630 +VMM: 0.623 +files: 0.623 +i386: 0.620 +user-level: 0.610 +risc-v: 0.525 +arm: 0.400 +TCG: 0.399 +kernel: 0.372 +register: 0.364 +mistranslation: 0.342 +KVM: 0.218 + +IPv4 guest/outbound port forwarding not working +Description of problem: +Python http server running on the host can receive the first http request from guest and provides correct response, but the resent request gets stuck. Package couldn't be seen in `tcpdump` running on host. +Steps to reproduce: +1. Build libslirp, I am using HEAD @ master. +1. Build your QEMU with user network enabled to use slirp (`./configure -target-list=x86_64-softmmu --enable-slirp`). +1. Ran a Python server on host listening to port `6655` (`python3 -m http.server --bind :: 6655`). +1. Boot your QEMU with aforementioned QEMU command line, I am forwarding a server address to host's local address `guestfwd=tcp:10.0.2.100:6657-tcp:127.0.0.1:6655`. For image, I am using a ordinary Fedora 38 workstation live cdrom. +1. In your guest OS (emulated enviroment), open a terminal and run `curl http://10.0.2.100:6657`, this sends a http get to the +slirp outbound forwarding server. You should see the Python http server gets the request and provides correct response `::ffff:127.0.0.1 - - [17/Aug/2023 18:24:34] "GET / HTTP/1.1" 200 -`, nothing but just `ls` the directory. +5. Repeat step 4, you will see the `curl` command gets stuck. +Additional information: +I've added a .pacp capturing line in QEMU command line and investigated it via Wireshark, noticed the slirp gets the http get, but after that being stuck in some place, I saw the guest sending keep alive request to slirp, so I think this could be something in the QEMU side. + + + + + diff --git a/results/classifier/118/graphic/1835477 b/results/classifier/118/graphic/1835477 new file mode 100644 index 000000000..f5510d155 --- /dev/null +++ b/results/classifier/118/graphic/1835477 @@ -0,0 +1,44 @@ +graphic: 0.865 +device: 0.840 +semantic: 0.683 +mistranslation: 0.656 +performance: 0.651 +boot: 0.644 +user-level: 0.619 +assembly: 0.543 +VMM: 0.516 +vnc: 0.486 +kernel: 0.485 +PID: 0.468 +ppc: 0.448 +socket: 0.442 +risc-v: 0.440 +permissions: 0.438 +register: 0.430 +architecture: 0.412 +debug: 0.370 +network: 0.370 +files: 0.350 +TCG: 0.296 +virtual: 0.287 +arm: 0.271 +hypervisor: 0.136 +peripherals: 0.133 +i386: 0.106 +x86: 0.103 +KVM: 0.082 + +Converting qcow2 to vmdk on MacOSX results in a non-bootable image + +When using qemu-img convert -O vmdk with version 3.1.0 or 4.0.0 on OSX (10.14.3) with a qcow2 image (https://cloud-images.ubuntu.com/bionic/20190703/bionic-server-cloudimg-amd64.img), the resulting image is not bootable. + +Running the same command on Ubuntu 18.04 results in a bootable image as expected + +Try the solutions in 1828508 ( -o adapter_type=lsilogic,subformat=monolithicFlat) 1776920 ( -S 0 ) do not work either + +What other steps can I take to troubleshoot? + +Does the problem happen only when the image is on APFS? when the destination is on APFS? Neither? Try to see if it's the filesystem. Use OSX to convert images on a non-APFS formatted external drive to see if that improves your luck. + +I'm assuming this is a duplicate of 1776920 which is still open because we have no OSX developers willing or able to debug this problem. + diff --git a/results/classifier/118/graphic/1835693 b/results/classifier/118/graphic/1835693 new file mode 100644 index 000000000..05f6548dd --- /dev/null +++ b/results/classifier/118/graphic/1835693 @@ -0,0 +1,54 @@ +graphic: 0.870 +architecture: 0.787 +device: 0.644 +mistranslation: 0.535 +boot: 0.491 +files: 0.459 +semantic: 0.422 +PID: 0.418 +user-level: 0.393 +ppc: 0.351 +socket: 0.322 +performance: 0.298 +arm: 0.284 +network: 0.280 +debug: 0.248 +register: 0.242 +x86: 0.242 +TCG: 0.239 +permissions: 0.228 +vnc: 0.220 +virtual: 0.216 +i386: 0.148 +hypervisor: 0.147 +peripherals: 0.085 +risc-v: 0.078 +assembly: 0.075 +kernel: 0.047 +VMM: 0.032 +KVM: 0.008 + +s390x binaries segfault + +Hello World appears to segfault with qemu s390x, on a Debian 10.0.0 Buster amd64 host. + +$ cat hello.cpp +#include <iostream> +using std::cout; + +int main() { + cout << "Hello World!\n"; + return 0; +} + +$ s390x-linux-gnu-g++ -o hello hello.cpp + +$ qemu-s390x-static hello +Segmentation fault + +Does "make check-tcg" work in this case? It works for me here. + +Which QEMU version are you using here? Can you reproduce this issue with the latest upstream QEMU ? ... otherwise, please report this issue to the Debian bug tracker instead. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1835729 b/results/classifier/118/graphic/1835729 new file mode 100644 index 000000000..35461089e --- /dev/null +++ b/results/classifier/118/graphic/1835729 @@ -0,0 +1,57 @@ +graphic: 0.807 +x86: 0.707 +device: 0.671 +mistranslation: 0.593 +performance: 0.552 +semantic: 0.527 +network: 0.435 +architecture: 0.428 +user-level: 0.410 +register: 0.403 +socket: 0.394 +permissions: 0.393 +debug: 0.376 +i386: 0.353 +files: 0.353 +ppc: 0.352 +PID: 0.345 +boot: 0.323 +vnc: 0.291 +kernel: 0.261 +risc-v: 0.258 +peripherals: 0.252 +hypervisor: 0.236 +arm: 0.231 +assembly: 0.205 +TCG: 0.191 +virtual: 0.169 +VMM: 0.168 +KVM: 0.122 + +GTK display does not support host scale factor + +In the GNOME desktop environment, for HiDPI displays there is support to upscale everything. + +This can be set in "System Settings -> Displays -> Scale". + +I believe this affects GDK in the same way as setting the "GDK_SCALE" environment variable does. + +When launching `qemu-system-x86_64 ... -display gtk`, this scale factor seems to get lost; the result is that the host window is upscaled and doubled in size, while the guest appears only in the bottom left corner of the UI. + + + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1835732 b/results/classifier/118/graphic/1835732 new file mode 100644 index 000000000..9018af2c7 --- /dev/null +++ b/results/classifier/118/graphic/1835732 @@ -0,0 +1,53 @@ +graphic: 0.960 +performance: 0.685 +device: 0.647 +mistranslation: 0.630 +semantic: 0.614 +kernel: 0.538 +assembly: 0.414 +architecture: 0.396 +PID: 0.368 +user-level: 0.364 +network: 0.349 +debug: 0.342 +socket: 0.326 +virtual: 0.314 +ppc: 0.309 +boot: 0.277 +permissions: 0.269 +i386: 0.269 +register: 0.247 +peripherals: 0.226 +files: 0.225 +vnc: 0.211 +TCG: 0.197 +x86: 0.181 +risc-v: 0.169 +VMM: 0.162 +arm: 0.121 +hypervisor: 0.114 +KVM: 0.069 + +GTK display zoom in, zooms infinitely + +The zoom in feature in the "View" menu of the gtk frontend (launch qemu with -display gtk), seems to be very broken. + +If I hit the zoom in feature, it first zooms in. + +Then, it zooms in again. + +Every subsequent second that passes, it zooms in again, until it eventually eats up too much host resources and freezes the host desktop. + +I have seen this with 3.1.0 (Debian 1:3.1+dfsg-8~deb10u1), and also with a locally built 4.0, My colleague also confirms having seen the issue with 3.1.0 (Debian 1:3.1+dfsg-8). + +This seems to work for me + +Can you confirm: + a) Guest OS and version + b) Guest desktop environment + c) Host OS version + d) Host desktop env + e) The full command line you used for qemu. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1836501 b/results/classifier/118/graphic/1836501 new file mode 100644 index 000000000..7986925de --- /dev/null +++ b/results/classifier/118/graphic/1836501 @@ -0,0 +1,156 @@ +semantic: 0.949 +graphic: 0.923 +assembly: 0.923 +permissions: 0.912 +mistranslation: 0.905 +arm: 0.898 +debug: 0.891 +performance: 0.890 +device: 0.888 +register: 0.878 +architecture: 0.876 +kernel: 0.874 +virtual: 0.873 +PID: 0.826 +user-level: 0.825 +boot: 0.819 +ppc: 0.805 +risc-v: 0.789 +VMM: 0.785 +hypervisor: 0.771 +files: 0.769 +peripherals: 0.749 +socket: 0.717 +KVM: 0.695 +TCG: 0.665 +network: 0.631 +x86: 0.619 +vnc: 0.619 +i386: 0.394 + +cpu_address_space_init fails with assertion + +qemu-system-arm does not start with version >= 2.6 and KVM enabled. + + cpu_address_space_init: Assertion `asidx == 0 || !kvm_enabled()' failed. + +Hardware is Odroid XU4 with Exynos with 4.9.61+ Tested with Debian Stretch (9) or Buster (10). + +Without KVM it is running fine but slow. I'm operating Debian Jessie with qemu 2.1 for a long time with KVM virtualization working flawlessly. When I upgraded to Stretch I ran into the trouble described before. I tried Debian Stretch and Buster with all Kernels provided by the Board manufacturer (Hardkernel). + +It seems to be related to the feature introduced in Version 2.6: +https://wiki.qemu.org/ChangeLog/2.6 +- Support for a separate EL3 address space + +KVM is enabled, so I assume the adress space index asidx to be causing the assert to fail. + +dmesg | grep -i KVM +[ 0.741714] kvm [1]: 8-bit VMID +[ 0.741721] kvm [1]: IDMAP page: 40201000 +[ 0.741729] kvm [1]: HYP VA range: c0000000:ffffffff +[ 0.742543] kvm [1]: Hyp mode initialized successfully +[ 0.742600] kvm [1]: vgic-v2@10484000 +[ 0.742924] kvm [1]: vgic interrupt IRQ16 +[ 0.742943] kvm [1]: virtual timer IRQ60 + +Full command line is: +qemu-system-arm -M vexpress-a15 -smp 2 -m 512 -cpu host -enable-kvm -kernel vmlinuz -initrd initrd.gz -dtb vexpress-v2p-ca15-tc1.dtb -device virtio-blk-device,drive=inst-blk -drive file=PATHTOFILE,id=inst-blk,if=none,format=raw -append "vga=normal rw console=ttyAMA0" -nographic + +Is there anything to do to understand, if this is a hardware related failure or probably just a missing parameter? + +Regards + +Lutz + +2.6 is now very old -- can you check whether this is still a problem with a more recent QEMU version, please? + +The command line you're using should in theory work, but vexpress-a15 + KVM is a bit of an obscure combination -- most people who want to use virtualization use the 'virt' machine, which supports more RAM and has PCI, unlike the vexpress-a15 board. So it's possible we broke it by accident and didn't notice. + + +Oh, I've just noticed -- we default to enabling EL3 on this board (like the hardware), which won't work with KVM, so if you want KVM you need to disable EL3 with the command line option -machine secure=off + + +We do check for the incompatible option combination in hw/arm/virt.c: + if (vms->secure) { + if (kvm_enabled()) { + error_report("mach-virt: KVM does not support Security extensions"); + exit(1); + } + +we just don't have anything equivalent in vexpress.c. We should probably put something in target/arm/cpu.c so we don't have to modify every board. + + +Thank you for the quick and complete investigation. I'll follow your suggestions and will reply any succecss in the next days. I checked the source of the vexpress and found the assert, but wasn't clever enough to compare it to another board. + +I would support the idea of checking the incompatible parameter pairing in common code. + +I've now tested this with both current head-of-git and with the Debian stretch 2.8.1 qemu-system-arm and I can't reproduce this. We automatically don't enable the EL3 feature if we're using KVM, so a guest runs and sees a non-secure only CPU, without needing to manually add -machine secure=off to the command line. Perhaps we fixed it between 2.6 and 2.8 ? + + +My test setup is now Debian Buster with qemu-system-arm 3.1 and a host with KVM-enabled Kernel 4.9.61 on Odroid XU4. + +Following results: +-------- +qemu-system-arm -M vexpress-a15 -smp 2 -m 512 -kernel vmlinuz -initrd initrd.gz -dtb vexpress-v2p-ca15-tc1.dtb -device virtio-blk-device,drive=inst-blk -drive file=PATHTOFILE,id=inst-blk,if=none,format=raw -append "vga=normal rw console=ttyAMA0" -nographic -enable-kvm + +Still not working as above, so it doesn't seem to be fixed for 3.1. +-------- +qemu-system-arm -M vexpress-a15,secure=off -smp 2 -m 512 -kernel vmlinuz -initrd initrd.gz -dtb vexpress-v2p-ca15-tc1.dtb -device virtio-blk-device,drive=inst-blk -drive file=PATHTOFILE,id=inst-blk,if=none,format=raw -append "vga=normal rw console=ttyAMA0" -nographic -enable-kvm + +No errors but no output at all, can switch to qemu monitor, but don't know if system is running +-------- +Option 1 and Option 2 both start the Debian installer as expected WITHOUT the parameter -enable-kvm + + +I did also tests with the virt board as recommended. With the parameter -enable-kvm none of the different virt-* boards did output anything to the console, without KVM the virt-boards did start. + +virt-2.6 and virt-2.7 did boot into the installer without KVM. + +Any more recent version (2.8, 2.9, 2.10, 3.0 and 3.1) returned + +"Unable to handle kernel paging request at virtual address 0109ed30" (address is changing) + +during the init process. With different guest memory sizes the paging error occurred at a different init step. + +Conclusion: +1) EL3 feature does still seem to be enabled in qemu 3.1 (Debian) even for KVM-enabled guests. +2) Any recommendation for a support forum to discuss my trouble with the missing console output when enabling KVM and the paging problems with the recent virt boards outside this bug report? + +UPDATE: Kernel page handling seems to be related to the -smp 2 parameter. Any number > 1 leads to the paging error while omitting the parameter lead to a running system (without KVM). + +I can boot a KVM guest (either with the debian stretch qemu-system-arm 2.8.1, or with a head-of-upstream-git QEMU), which wouldn't work with EL3 enabled, so I'm not sure what is going wrong for you. To try to debug this further you'd need to build QEMU from source and start running it under the debugger to see what exactly is going on and why it's hitting that assertion. + +I would be tempted to try a newer kernel to see if that helped. (My working setup is using the debian stretch stock "4.9.0-0.bpo.9-armmp-lpae #1 SMP Debian 4.9.168-1+deb9u3~deb8u1 (2019-06-17)", but in general 4.9 is fairly elderly now.) + +For forums to talk about this kind of thing you might also try the qemu-arm mailing list (https://lists.nongnu.org/mailman/listinfo/qemu-arm) or qemu-devel itself (generally best to cc qemu-devel on qemu-arm emails anyway, lots of people don't subscribe to the per-architecture lists). + + +I'm marking this bug 'incomplete' since as in comment #8 I was unable to reproduce, and I'm no longer sure how the assert could be being hit. If you can provide repro instructions and images that work on current head-of-git I can investigate. + + +[Expired for QEMU because there has been no activity for 60 days.] + +I am having a similar problem. I want to use KVM on jetson nano and boot Raspbian Buster 32bit OS with native machine emulation. + +Run into a similar problem. I used latest QEMU. + + +When I use gdb i see that the assert line uses: + + /* KVM cannot currently support multiple address spaces. */ + assert(asidx == 0 || !kvm_enabled()); + +the asidx is 1. So since KVM is not supporting multiple addresses spaces that the Raspi3 requires the assertion occurs. + +I wonder what the workaround could be for this + + + + +> I want to use KVM on jetson nano and boot Raspbian Buster 32bit OS with native machine emulation. + +The raspi machine doesn't support KVM. You can choose either (1) boot on a board model which does support KVM, which basically means "virt", or (2) use emulation, not KVM. + +If all you care about is running a fairly generic Linux userspace then option 1 will probably be good enough. + + diff --git a/results/classifier/118/graphic/1836762 b/results/classifier/118/graphic/1836762 new file mode 100644 index 000000000..650b42a41 --- /dev/null +++ b/results/classifier/118/graphic/1836762 @@ -0,0 +1,181 @@ +graphic: 0.808 +KVM: 0.753 +virtual: 0.700 +TCG: 0.699 +ppc: 0.695 +permissions: 0.693 +vnc: 0.693 +device: 0.679 +peripherals: 0.673 +hypervisor: 0.672 +register: 0.651 +VMM: 0.649 +architecture: 0.630 +mistranslation: 0.622 +arm: 0.614 +x86: 0.607 +debug: 0.606 +user-level: 0.605 +PID: 0.600 +kernel: 0.583 +assembly: 0.580 +performance: 0.577 +files: 0.574 +socket: 0.571 +i386: 0.550 +boot: 0.535 +semantic: 0.505 +risc-v: 0.474 +network: 0.440 + +Many leaks from qemu_spice_create_update + +tag: v4.1.0-rc0 + +Compiled with --enable-sanitizers + +$ qemu-system-x86_64 -device qxl-vga ... +[guest exits calling 'hlt'] +==20452==ERROR: LeakSanitizer: detected memory leaks + +Direct leak of 167616 byte(s) in 582 object(s) allocated from: + #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef) + #1 0x7f73af3dde1d in g_malloc0 (/lib64/libglib-2.0.so.0+0x54e1d) + #2 0x561148c6d547 in qemu_spice_create_update qemu/ui/spice-display.c:222:21 + #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9 + #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9 + #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13 + #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5 + #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9 + #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12 + #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25 + #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5 + #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9 + #12 0x561147c4976d in main qemu/vl.c:4473:5 + #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412) + +Direct leak of 5184 byte(s) in 18 object(s) allocated from: + #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef) + #1 0x7f73af3dde1d in g_malloc0 (/lib64/libglib-2.0.so.0+0x54e1d) + #2 0x561148c6e3e7 in qemu_spice_create_update qemu/ui/spice-display.c:243:13 + #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9 + #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9 + #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13 + #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5 + #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9 + #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12 + #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25 + #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5 + #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9 + #12 0x561147c4976d in main qemu/vl.c:4473:5 + #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412) + +Direct leak of 2560 byte(s) in 4 object(s) allocated from: + #0 0x561146f2cb46 in realloc (x86_64-softmmu/qemu-system-x86_64+0x1824b46) + #1 0x7f73ac04c420 (/lib64/libfontconfig.so.1+0x21420) + +Direct leak of 22 byte(s) in 1 object(s) allocated from: + #0 0x561146f2c6af in __interceptor_malloc (x86_64-softmmu/qemu-system-x86_64+0x18246af) + #1 0x7f73ae781953 in XGetAtomName (/lib64/libX11.so.6+0x2a953) + +Indirect leak of 54936 byte(s) in 510 object(s) allocated from: + #0 0x561146f2c6af in __interceptor_malloc (x86_64-softmmu/qemu-system-x86_64+0x18246af) + #1 0x7f73af3dddc5 in g_malloc (/lib64/libglib-2.0.so.0+0x54dc5) + #2 0x561148c6d547 in qemu_spice_create_update qemu/ui/spice-display.c:222:21 + #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9 + #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9 + #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13 + #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5 + #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9 + #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12 + #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25 + #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5 + #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9 + #12 0x561147c4976d in main qemu/vl.c:4473:5 + #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412) + +Indirect leak of 30720 byte(s) in 23 object(s) allocated from: + #0 0x561146f2c6af in __interceptor_malloc (x86_64-softmmu/qemu-system-x86_64+0x18246af) + #1 0x7f73af3dddc5 in g_malloc (/lib64/libglib-2.0.so.0+0x54dc5) + #2 0x561148c6e3e7 in qemu_spice_create_update qemu/ui/spice-display.c:243:13 + #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9 + #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9 + #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13 + #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5 + #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9 + #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12 + #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25 + #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5 + #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9 + #12 0x561147c4976d in main qemu/vl.c:4473:5 + #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412) + +Indirect leak of 8288 byte(s) in 259 object(s) allocated from: + #0 0x561146f2c6af in __interceptor_malloc (x86_64-softmmu/qemu-system-x86_64+0x18246af) + #1 0x7f73ac0385af (/lib64/libfontconfig.so.1+0xd5af) + +Indirect leak of 4068 byte(s) in 303 object(s) allocated from: + #0 0x561146e78f40 in __interceptor_strdup (x86_64-softmmu/qemu-system-x86_64+0x1770f40) + #1 0x7f73ac04bc44 in FcValueSave (/lib64/libfontconfig.so.1+0x20c44) + +Indirect leak of 2336 byte(s) in 73 object(s) allocated from: + #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef) + #1 0x7f73ac04c9cc (/lib64/libfontconfig.so.1+0x219cc) + +Indirect leak of 1536 byte(s) in 48 object(s) allocated from: + #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef) + #1 0x7f73ac04bf0c (/lib64/libfontconfig.so.1+0x20f0c) + +Indirect leak of 1440 byte(s) in 5 object(s) allocated from: + #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef) + #1 0x7f73af3dde1d in g_malloc0 (/lib64/libglib-2.0.so.0+0x54e1d) + #2 0x561148c6e3e7 in qemu_spice_create_update qemu/ui/spice-display.c:243:13 + #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9 + #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9 + #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13 + #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5 + #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9 + #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12 + #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25 + #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5 + #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9 + #12 0x561147c4976d in main qemu/vl.c:4473:5 + #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412) + +Indirect leak of 1440 byte(s) in 5 object(s) allocated from: + #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef) + #1 0x7f73af3dde1d in g_malloc0 (/lib64/libglib-2.0.so.0+0x54e1d) + #2 0x561148c6d547 in qemu_spice_create_update qemu/ui/spice-display.c:222:21 + #3 0x561148c6ba2b in qemu_spice_display_refresh qemu/ui/spice-display.c:488:9 + #4 0x561148172eff in display_refresh qemu/hw/display/qxl.c:2030:9 + #5 0x561148c2748f in dpy_refresh qemu/ui/console.c:1629:13 + #6 0x561148c263f1 in gui_update qemu/ui/console.c:206:5 + #7 0x561149558e6b in timerlist_run_timers qemu/util/qemu-timer.c:574:9 + #8 0x5611495591de in qemu_clock_run_timers qemu/util/qemu-timer.c:588:12 + #9 0x56114955a489 in qemu_clock_run_all_timers qemu/util/qemu-timer.c:708:25 + #10 0x56114955b235 in main_loop_wait qemu/util/main-loop.c:519:5 + #11 0x561147c587b3 in main_loop qemu/vl.c:1791:9 + #12 0x561147c4976d in main qemu/vl.c:4473:5 + #13 0x7f73ac5c4412 in __libc_start_main (/lib64/libc.so.6+0x24412) + +Indirect leak of 384 byte(s) in 12 object(s) allocated from: + #0 0x561146f2c8ef in calloc (x86_64-softmmu/qemu-system-x86_64+0x18248ef) + #1 0x7f73ac04bd9e (/lib64/libfontconfig.so.1+0x20d9e) + +Indirect leak of 96 byte(s) in 2 object(s) allocated from: + #0 0x561146f2c6af in __interceptor_malloc (x86_64-softmmu/qemu-system-x86_64+0x18246af) + #1 0x7f73ac045e51 in FcLangSetCreate (/lib64/libfontconfig.so.1+0x1ae51) + +SUMMARY: AddressSanitizer: 280628 byte(s) leaked in 1847 allocation(s). + +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 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/231 + + diff --git a/results/classifier/118/graphic/1839294 b/results/classifier/118/graphic/1839294 new file mode 100644 index 000000000..ab27cf347 --- /dev/null +++ b/results/classifier/118/graphic/1839294 @@ -0,0 +1,57 @@ +graphic: 0.865 +files: 0.821 +device: 0.720 +semantic: 0.671 +ppc: 0.634 +performance: 0.595 +architecture: 0.577 +socket: 0.448 +assembly: 0.421 +network: 0.401 +arm: 0.400 +permissions: 0.384 +vnc: 0.376 +hypervisor: 0.359 +PID: 0.356 +register: 0.341 +kernel: 0.335 +user-level: 0.316 +mistranslation: 0.313 +boot: 0.268 +peripherals: 0.266 +TCG: 0.258 +VMM: 0.219 +risc-v: 0.208 +debug: 0.200 +KVM: 0.182 +x86: 0.146 +virtual: 0.144 +i386: 0.103 + +Latest Installer (qemu-w64-setup-20190807.exe) for windows immediately deletes installed files at the very end of the installation + +This happens on Windows 10 with the latest installer for 64 bit Windows: qemu-w64-setup-20190807.exe + +On install it will create the files and go through all the typical functions of installing the software, at the very end step it will then delete all files the installer created. + +I looked for logs to see when was going on so I ran the installation in Sandboxie and was able to retain all the installed files but I couldn't find a log for the installer. + +Here is a screenshot of it deleting all the files at the end of the process. + +https://imgur.com/BWiTA38 + +If goes too fast for me to see what is written in the text console otherwise I would post more information but this is all I have. It does not give any error or any other information at completion. + +This error does not occur in the earlier release: qemu-w64-setup-20190731.exe + + + +I hit the same error in my azure pipelines script that uses `choco install qemu`. While it worked with qemu-w64-setup-20190731.exe, the `C:\Program Files\qemu` directory is empty with qemu-w64-setup-20190807.exe. + +We can forget this one if nothing happens from now on; however, this problem might have a rare but systemic problem. We can always wait and see if this problem is ever duplicated. In which case there is at least a commonality to the bug. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1840250 b/results/classifier/118/graphic/1840250 new file mode 100644 index 000000000..2f8f12691 --- /dev/null +++ b/results/classifier/118/graphic/1840250 @@ -0,0 +1,51 @@ +graphic: 0.853 +device: 0.671 +mistranslation: 0.663 +semantic: 0.652 +arm: 0.629 +PID: 0.606 +ppc: 0.593 +hypervisor: 0.585 +network: 0.556 +kernel: 0.548 +socket: 0.536 +performance: 0.523 +vnc: 0.511 +architecture: 0.509 +user-level: 0.500 +permissions: 0.498 +VMM: 0.497 +peripherals: 0.487 +i386: 0.480 +x86: 0.475 +files: 0.423 +register: 0.419 +virtual: 0.407 +KVM: 0.395 +assembly: 0.382 +risc-v: 0.375 +debug: 0.332 +boot: 0.307 +TCG: 0.263 + +'make -j1 docker-test-build' uses more than one job + +version: v4.1.0-rc5 + +Run 'make -j1 docker-test-build', wait a few, various containers get instantiated. + +$ make -j1 docker-test-build 2>&1 > /dev/null + +On another terminal: + +$ 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 QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1844 b/results/classifier/118/graphic/1844 new file mode 100644 index 000000000..4e63e0a15 --- /dev/null +++ b/results/classifier/118/graphic/1844 @@ -0,0 +1,52 @@ +graphic: 0.951 +device: 0.893 +performance: 0.786 +files: 0.764 +semantic: 0.764 +architecture: 0.716 +PID: 0.714 +VMM: 0.689 +boot: 0.660 +virtual: 0.652 +user-level: 0.651 +debug: 0.609 +vnc: 0.580 +permissions: 0.577 +mistranslation: 0.559 +hypervisor: 0.553 +ppc: 0.499 +network: 0.460 +x86: 0.455 +risc-v: 0.440 +peripherals: 0.435 +register: 0.431 +i386: 0.413 +TCG: 0.409 +socket: 0.349 +KVM: 0.340 +arm: 0.335 +assembly: 0.329 +kernel: 0.276 + +qemu process memory usage greater than windows guest memory usage +Description of problem: +The Windows Guest internal memory usage is low,but is very high on host of qemu progress. But the linux guest is no such case.Is there any way to trigger the host to reclaim virtual machine memory? +Steps to reproduce: +1.install a windows guest with 128GB of memory and start it. + +2.When the machine is stable, the VM internal memory usage is low,but is very high on host of qemu progress. + +3.on host,use "free -g" to query,the memory used is also very high + +4.when migrate or dormancy,it can recovery,but I want to know is there any way to trigger the host to reclaim virtual machine memory? + + +host: + + + + + +guest: + + diff --git a/results/classifier/118/graphic/1854910 b/results/classifier/118/graphic/1854910 new file mode 100644 index 000000000..784f8ab05 --- /dev/null +++ b/results/classifier/118/graphic/1854910 @@ -0,0 +1,49 @@ +graphic: 0.854 +device: 0.771 +hypervisor: 0.610 +performance: 0.605 +architecture: 0.605 +register: 0.590 +network: 0.570 +files: 0.569 +semantic: 0.567 +mistranslation: 0.528 +permissions: 0.519 +peripherals: 0.518 +i386: 0.516 +risc-v: 0.499 +vnc: 0.478 +PID: 0.477 +ppc: 0.464 +user-level: 0.453 +kernel: 0.450 +VMM: 0.439 +socket: 0.437 +virtual: 0.430 +x86: 0.401 +debug: 0.400 +assembly: 0.396 +TCG: 0.357 +arm: 0.354 +boot: 0.343 +KVM: 0.315 + +Support VHDX differencing images (ie images with backing) + +The qemu vhdx driver does not support type 2 (differencing) vhdx images (usually stored with file extension .avhdx). This means that any hyperv images with snapshots are not supported by qemu-img. It would be great to be able to convert to a new qcow image from a backing + set of differencing images from hyperv, and/or convert an individual differencing vhdx image to a qcow2 image with a backing file specified. + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1856 b/results/classifier/118/graphic/1856 new file mode 100644 index 000000000..35db10b03 --- /dev/null +++ b/results/classifier/118/graphic/1856 @@ -0,0 +1,43 @@ +TCG: 0.949 +graphic: 0.927 +files: 0.901 +performance: 0.899 +network: 0.856 +device: 0.829 +register: 0.824 +debug: 0.820 +vnc: 0.812 +kernel: 0.798 +peripherals: 0.781 +socket: 0.772 +VMM: 0.749 +architecture: 0.745 +PID: 0.725 +ppc: 0.706 +risc-v: 0.681 +semantic: 0.655 +permissions: 0.652 +boot: 0.647 +arm: 0.634 +hypervisor: 0.471 +x86: 0.427 +assembly: 0.402 +user-level: 0.376 +virtual: 0.337 +i386: 0.334 +mistranslation: 0.296 +KVM: 0.260 + +Replay got stuck with consecutive hardware interrupts coming +Description of problem: +I recorded bin file using **_rr=record_** command line. But it got stuck when replaying this record bin file. The icount number would never change after stucking if I typed _**info replay**_ with qmp command line. + +I found that the following instructions should be a sequence of consecutive hardware interrupts after stucking once checking the trace log of +both replay and record log using _**-d in_asm,int**_. +Steps to reproduce: +1.pulling from remote which the newest commit ID is 156618d9ea67f2f2e31d9dedd97f2dcccbe6808c +2.emulating Windows 7 OS on aarch64 Host with TCG acceleration mechanism +3.using **_rr=record_** to make replay file and tracing guest code and interrupts using _**-d in_asm,int**_ +4.replaying the previous file and also tracing guest code and interrupts +Additional information: +# diff --git a/results/classifier/118/graphic/1856724 b/results/classifier/118/graphic/1856724 new file mode 100644 index 000000000..e656d9d69 --- /dev/null +++ b/results/classifier/118/graphic/1856724 @@ -0,0 +1,85 @@ +graphic: 0.974 +user-level: 0.973 +device: 0.953 +mistranslation: 0.947 +virtual: 0.943 +peripherals: 0.937 +assembly: 0.932 +architecture: 0.913 +performance: 0.911 +semantic: 0.898 +ppc: 0.846 +permissions: 0.836 +register: 0.834 +kernel: 0.804 +arm: 0.799 +debug: 0.783 +network: 0.776 +risc-v: 0.767 +KVM: 0.763 +hypervisor: 0.744 +files: 0.744 +VMM: 0.742 +socket: 0.700 +vnc: 0.695 +i386: 0.681 +TCG: 0.661 +boot: 0.632 +PID: 0.628 +x86: 0.622 + +SB.PCI0.SMB0 device drivers unavailable + +QEMU 4.2 introduces new device with this code: + +static void build_smb0(Aml *table, I2CBus *smbus, int devnr, int func) +{ + Aml *scope = aml_scope("_SB.PCI0"); + Aml *dev = aml_device("SMB0"); + + aml_append(dev, aml_name_decl("_HID", aml_eisaid("APP0005"))); + aml_append(dev, aml_name_decl("_ADR", aml_int(devnr << 16 | func))); + build_acpi_ipmi_devices(dev, BUS(smbus), "\\_SB.PCI0.SMB0"); + aml_append(scope, dev); + aml_append(table, scope); +} + +It is detected by Windows 10 as 'Unknown Device' and there is no driver available. +Please provide a working Windows driver or give ability to disable this device. + +what is this shit? + +I noticed this as well. Apparently it was introduced in the following commit: + +https://github.com/qemu/qemu/commit/ebe15582cafeb944a1c6e99aa526e81a1551c567 + +Saying: + +--- +pc: Add an SMB0 ACPI device to q35 + +This is so I2C devices can be found in the ACPI namespace. Currently +that's only IPMI, but devices can be easily added now. + +Adding the devices required some PCI information, and the bus itself +to be added to the PCMachineState structure. + +Note that this only works on Q35, the ACPI for PIIX4 is not capable +of handling an SMBus device. + +Cc: Michael S. Tsirkin <email address hidden> +Cc: Igor Mammedov <email address hidden> +Signed-off-by: Corey Minyard <email address hidden> +Reviewed-by: Paolo Bonzini <email address hidden> +--- + +Any progress? When will you provide a Windows driver for this and/or ability to disable this device in Qemu? + +I'm also having this issue on a Win 10 VM running on a unRaid server. + + + +Hi, although this isn't my area of expertise, the bug caught my eye. Peter Maydell points out that there is a commit that addresses this issue: https://github.com/qemu/qemu/commit/aefcaf9d1b3ebb30981627bd08f595211a648a62 + +It just never made its way back here to launchpad. + diff --git a/results/classifier/118/graphic/1857449 b/results/classifier/118/graphic/1857449 new file mode 100644 index 000000000..0cccd0393 --- /dev/null +++ b/results/classifier/118/graphic/1857449 @@ -0,0 +1,81 @@ +graphic: 0.872 +x86: 0.867 +semantic: 0.788 +user-level: 0.759 +kernel: 0.736 +device: 0.733 +ppc: 0.687 +performance: 0.682 +architecture: 0.670 +mistranslation: 0.651 +VMM: 0.579 +risc-v: 0.566 +socket: 0.564 +vnc: 0.542 +register: 0.539 +boot: 0.532 +debug: 0.517 +PID: 0.517 +arm: 0.509 +network: 0.497 +TCG: 0.476 +hypervisor: 0.471 +permissions: 0.469 +i386: 0.465 +files: 0.461 +virtual: 0.456 +peripherals: 0.347 +assembly: 0.337 +KVM: 0.239 + +QEMU x86_64 -nographic full system breaks host Bash terminal line wrapping state after simulation ends, requires reset or "tput smam" to fix it + +QEMU 4.2.0 compiled from source, Ubuntu 19.10, open a fresh new gnome terminal. + +If you print 1000 = chars on the host terminal, then they do wrap around the end of the terminal: + +printf "=%.0s" {0..1000} + +However, if you first run QEMU: + +x86_64-softmmu/qemu-system-x86_64 -nographic + +and then quit it in any way, e.g. with Ctrl + A, and then re-run on the host terminal: + +printf "=%.0s" {0..1000} + +then the signs don't wrap around anymore, they just go "off the terminal to the right". + +This can be fixed with either: + +reset +tpam smam + +but unfortunately those don't work in tmux for some reason: https://github.com/tmux/tmux/issues/969 + +I consider this buggy behavior, QEMU should restore the original terminal state if possible. + +Related: https://github.com/cirosantilli/linux-kernel-module-cheat/issues/110 + +Apparently the code you run (BIOS?) is sending the DECRST control sequence to the terminal, which disable the auto-wrap mode flag. +Looking at the detailed explanations on https://github.com/mattiase/wraptest I'm not sure how QEMU can save/restore this flag. + + +Ah, thanks for looking into this and identifying it to guest code Philippe. I don't know much about terminals, but yes, they are such archaic interfaces, maybe there is no API for 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. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1858623 b/results/classifier/118/graphic/1858623 new file mode 100644 index 000000000..10cf8b655 --- /dev/null +++ b/results/classifier/118/graphic/1858623 @@ -0,0 +1,60 @@ +graphic: 0.835 +vnc: 0.809 +device: 0.711 +performance: 0.663 +network: 0.621 +semantic: 0.564 +user-level: 0.530 +virtual: 0.510 +risc-v: 0.439 +ppc: 0.431 +PID: 0.427 +mistranslation: 0.392 +kernel: 0.358 +permissions: 0.344 +files: 0.341 +arm: 0.323 +register: 0.315 +socket: 0.315 +boot: 0.311 +architecture: 0.304 +debug: 0.284 +peripherals: 0.283 +x86: 0.271 +i386: 0.260 +VMM: 0.258 +TCG: 0.248 +hypervisor: 0.224 +KVM: 0.190 +assembly: 0.150 + +VNC outputs garbage in zlib mode + +TL;DR: When QEMU is launched with VNC as the output and viewed with a client that defaults to zlib VNC encoding, the resulting output tends to accumulate artifacts. + +Reproduction: +Launch QEMU (tried with versions 4.2.0 and 4.1.0 on Linux 64bit) with -vnc 0.0.0.0:0 +Connect to it with a VNC client that allows you to select encoding, i.e. UltraVNC. +Set encoding to zlib (type 6), 32bit color. +As screen content changes it starts accumulating artifacts. Almost certain to appear if you open-close windows over a pattern. +Does not seem to depend on guest used, but easier to reproduce with a GUI. + +Looks like this: https://orbides.org/img/vnc.png + +It appears to be a deflate glitch of some sort - all of the bad pixels are generated by length/distance codes. Can't narrow it down any more. + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1859723 b/results/classifier/118/graphic/1859723 new file mode 100644 index 000000000..2556c1316 --- /dev/null +++ b/results/classifier/118/graphic/1859723 @@ -0,0 +1,53 @@ +graphic: 0.944 +device: 0.719 +performance: 0.686 +vnc: 0.614 +socket: 0.609 +network: 0.599 +permissions: 0.550 +i386: 0.535 +register: 0.528 +risc-v: 0.516 +peripherals: 0.511 +mistranslation: 0.493 +architecture: 0.492 +semantic: 0.491 +files: 0.486 +hypervisor: 0.477 +x86: 0.455 +arm: 0.444 +user-level: 0.441 +VMM: 0.430 +boot: 0.426 +ppc: 0.399 +assembly: 0.396 +debug: 0.389 +PID: 0.372 +TCG: 0.344 +kernel: 0.306 +virtual: 0.233 +KVM: 0.200 + +Qemu ungrabs before cursor reaches border + +This was first reported https://bugzilla.redhat.com/show_bug.cgi?id=1285378 + +video: https://peertube.co.uk/videos/watch/fedaa432-79ef-4d30-bd0e-26c806e48db0 + +version: QEMU emulator version 4.2.0 + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1861394 b/results/classifier/118/graphic/1861394 new file mode 100644 index 000000000..f712e8c10 --- /dev/null +++ b/results/classifier/118/graphic/1861394 @@ -0,0 +1,60 @@ +graphic: 0.871 +boot: 0.830 +kernel: 0.826 +architecture: 0.817 +x86: 0.783 +risc-v: 0.734 +device: 0.706 +vnc: 0.698 +permissions: 0.694 +ppc: 0.690 +semantic: 0.687 +mistranslation: 0.671 +register: 0.637 +debug: 0.633 +user-level: 0.599 +files: 0.598 +performance: 0.569 +socket: 0.559 +PID: 0.556 +hypervisor: 0.498 +network: 0.488 +arm: 0.450 +TCG: 0.398 +VMM: 0.378 +peripherals: 0.365 +virtual: 0.355 +i386: 0.280 +assembly: 0.279 +KVM: 0.230 + +qemu-system-riscv64 hangs after poweroff linux command + +QEMU Version : v4.2.0-773-g43d1455-dirty (commit 43d1455cf84283466e5c22a217db5ef4b8197b14) + +Command: qemu-system-riscv64 -machine virt -kernel ./bbl -nographic -initrd rootfs.cpio.gz -append "root=/dev/ram console=ttyS0" + +Host:LSB Version: :core-4.1-amd64:core-4.1-noarch +Distributor ID: CentOS +Description: CentOS Linux release 7.7.1908 (Core) +Release: 7.7.1908 +Codename: Core + + +Problem: after boot, when type poweroff -f it hangs (not quitting). I have tested this for x86_64, and aarch64 and it works fine. The problem appears only for risv64(of those mentioned). Last time i have checked it worked also for riscv64 and it was on the d0f90e1423b4f412adc620eee93e8bfef8af4117 commit + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1862 b/results/classifier/118/graphic/1862 new file mode 100644 index 000000000..ed43b4b1a --- /dev/null +++ b/results/classifier/118/graphic/1862 @@ -0,0 +1,48 @@ +graphic: 0.937 +semantic: 0.685 +network: 0.552 +device: 0.470 +user-level: 0.399 +x86: 0.398 +peripherals: 0.355 +ppc: 0.308 +performance: 0.247 +PID: 0.226 +files: 0.212 +assembly: 0.198 +socket: 0.190 +hypervisor: 0.189 +mistranslation: 0.185 +architecture: 0.170 +debug: 0.169 +vnc: 0.136 +risc-v: 0.130 +i386: 0.124 +boot: 0.107 +kernel: 0.080 +TCG: 0.069 +arm: 0.068 +virtual: 0.065 +register: 0.062 +permissions: 0.045 +VMM: 0.038 +KVM: 0.020 + +SVGA/VESA strange colors (NetWare 6.x) +Description of problem: +The text mode part of the installation is correct but whenever the X server is starting, the display seems to be in 16 colors although GUI settings shows "SVGA/256 colors" (NetWare setup reports a "SVGA Plug & Play" display, VESA 2.0 compliance expected). Color depth issue with VESA? Telling NetWare to use explicitly the Cirrus Logic driver for a CL GD 5446 bring the display back to normal and colors are displayed as they should. +Steps to reproduce: +1. Grab a NetWare 6.0 installation ISO on some abandonware site (no need of a license key, unlicensed = 2 users max.) +2. Execute the command line above +3. Complete the text-mode part (defaults choices are fine) +Additional information: +NetWare 6.0 + Qemu => Same issue. SVGA PnP with wrong colors. +NetWare 6.5 + Qemu => Same issue. SVGA PnP with wrong colors. +NetWare 6.0 + PCem/86Box => does not exhibit the issue. Colors are normal. + +Using SeaBIOS 1.16. + +Screenshots: + + + diff --git a/results/classifier/118/graphic/1863678 b/results/classifier/118/graphic/1863678 new file mode 100644 index 000000000..eb9087979 --- /dev/null +++ b/results/classifier/118/graphic/1863678 @@ -0,0 +1,46 @@ +graphic: 0.916 +device: 0.787 +architecture: 0.741 +mistranslation: 0.566 +virtual: 0.563 +network: 0.452 +socket: 0.428 +permissions: 0.415 +semantic: 0.381 +register: 0.377 +performance: 0.359 +vnc: 0.355 +peripherals: 0.301 +files: 0.299 +kernel: 0.260 +PID: 0.249 +user-level: 0.248 +ppc: 0.234 +debug: 0.226 +boot: 0.212 +hypervisor: 0.177 +VMM: 0.165 +risc-v: 0.122 +arm: 0.101 +i386: 0.094 +TCG: 0.065 +assembly: 0.058 +x86: 0.054 +KVM: 0.042 + +qemu and virtio-vga black screen in Android + +QEMU emulator version 4.2.50 + +kernel 5.3.0-29-generic +host Ubuntu 19.10 +guest: Android 8.1 + +While trying to compile I get the following error + +qemu/slirp/src/misc.c:146: undefined reference to `g_spawn_async_with_fds' + +slirp is a separate project now ... if the problem persists, could you please report this in the https://gitlab.freedesktop.org/slirp/libslirp/-/issues bug tracker? Thanks! + +I'm closing this now. If the problem still persists, please report it to libslirp instead. + diff --git a/results/classifier/118/graphic/1864984 b/results/classifier/118/graphic/1864984 new file mode 100644 index 000000000..863532358 --- /dev/null +++ b/results/classifier/118/graphic/1864984 @@ -0,0 +1,61 @@ +graphic: 0.922 +virtual: 0.862 +boot: 0.776 +hypervisor: 0.708 +user-level: 0.706 +performance: 0.668 +device: 0.609 +semantic: 0.554 +mistranslation: 0.494 +network: 0.439 +peripherals: 0.429 +kernel: 0.411 +architecture: 0.381 +i386: 0.357 +arm: 0.341 +vnc: 0.337 +ppc: 0.336 +x86: 0.323 +register: 0.291 +debug: 0.290 +PID: 0.288 +permissions: 0.266 +risc-v: 0.258 +socket: 0.230 +files: 0.229 +TCG: 0.188 +VMM: 0.180 +assembly: 0.119 +KVM: 0.111 + +"nr_entries is too big" when using virgl + +I have a bootable image where GNOME Shell fails because it hits a limit in virtio-gpu. + +In `hw/display/virtio-gpu.c`, there is a limit for `nr_entries` at 16384. There is no explanation for that limit. But there does not seem to be any limit on the kernel side. + +Raising this limit with a patch to 262144 solves the issue. + +Could there be an explanation why this limit is needed? And why this value? Or could this limit be just removed? + +/me wonders what gnome shell is doing there ... + +It is the number of scatter list entries for resources. Even in the worst case (no chunks are continous in memory so each single page needs an entry) this is enough for 64 MB. An 4k display +framebuffer needs less than that. + +Removing the limit isn't an option. Raising maybe. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1865248 b/results/classifier/118/graphic/1865248 new file mode 100644 index 000000000..f83f8f07f --- /dev/null +++ b/results/classifier/118/graphic/1865248 @@ -0,0 +1,44 @@ +graphic: 0.982 +VMM: 0.873 +virtual: 0.859 +user-level: 0.821 +device: 0.817 +performance: 0.768 +network: 0.762 +architecture: 0.745 +permissions: 0.735 +mistranslation: 0.719 +PID: 0.688 +semantic: 0.665 +files: 0.649 +vnc: 0.648 +socket: 0.638 +assembly: 0.634 +register: 0.608 +arm: 0.595 +risc-v: 0.586 +kernel: 0.558 +ppc: 0.541 +debug: 0.514 +boot: 0.488 +peripherals: 0.438 +TCG: 0.419 +hypervisor: 0.399 +i386: 0.265 +x86: 0.192 +KVM: 0.187 + +bundle QEMU installer with a QEMU GUI (graphical user interface) such as Virt Manager + +For a better out of the box user experience on the Windows platform it would be nice if a QEMU GUI would be by installed by the same QEMU installer. Currently it is required to first install QEMU and then install a QEMU GUI. + +I don't know all QEMU GUIs but looks like Virt Manager is a decent QEMU GUI and still maintained. + +Virt Manager is also available for Windows. + +https://serverfault.com/questions/340949/is-there-a-way-to-run-virt-manager-on-windows + +However as per these instructions it is difficult (many steps) for laymen to install Virt Manager on Windows (cygwin...). + +Sorry, but I don't think that any of the current QEMU project members has plans to work on such a bundle. This requires a new contributor to step up and do the job. + diff --git a/results/classifier/118/graphic/1869782 b/results/classifier/118/graphic/1869782 new file mode 100644 index 000000000..802fb98bb --- /dev/null +++ b/results/classifier/118/graphic/1869782 @@ -0,0 +1,81 @@ +graphic: 0.862 +arm: 0.737 +kernel: 0.718 +architecture: 0.694 +device: 0.653 +ppc: 0.630 +semantic: 0.543 +vnc: 0.531 +register: 0.519 +virtual: 0.512 +performance: 0.509 +socket: 0.490 +user-level: 0.488 +hypervisor: 0.476 +permissions: 0.409 +PID: 0.387 +risc-v: 0.346 +files: 0.345 +peripherals: 0.341 +network: 0.337 +mistranslation: 0.319 +debug: 0.313 +assembly: 0.301 +TCG: 0.299 +x86: 0.282 +VMM: 0.277 +boot: 0.276 +i386: 0.242 +KVM: 0.198 + +qemu-arm-static crashes "segmentation fault" when running "svn checkout" + +I'm not actually sure how far I can help as I so far failed to reproduce the issue on my local VM but I get it on Travis CI every time. I even went through the hassle of hacking a Debian repository into their Ubuntu Bionic VM to get qemu 4.2 as I hoped a new version could fix this. + +Here is where the error occured: https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/309106220#L5420 + +I don't get this error with an armv7h chroot. + +Maybe now I'll just try to remove all uses of svn in my build scripts... + +Is it actually a viable solution to cross-build with qemu? I'm starting to doubt it... + +Would it help if I manage to get this core dump out of Travis somehow (maybe make Travis push it to some GIT or upload it to my webserver)? + +Is there a way that you can confirm that the QEMU being used to execute the binaries in the chroot really really is the new one you think it is? In this kind of setup where there's a chroot and somebody else's CI system and so on it can be quite easy for eg the new qemu binary not to get copied into the chroot so it's using the old version still, or whatever. So being able to rule that kind of possibility out would be helpful. + + +I could run an "qemu... --version" in the chroot to get it into log. + +But I'm close to 100% sure it is version 4.2 as the VM is set up from scratch for every build and the chroot is also set up from scratch. + +Here we go: +https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/309187889#L332 + +Created with this commit: +https://github.com/VDR4Arch/vdr4arch/commit/29ec2197483bf15102c889eef2749bb0cffc0839 + +This is a "Ubuntu Bionic" thing. + +I've tried again on a VM with up-to-date Ubuntu Bionic and get the same segfault. + +For comparison I've placed the Debian build of qemu-user-static version 4.2 to my Arch Linux VM and have no crash there. + +So either the kernel version or some kernel configuration. Now I'm trying to get a coredump on my VM. + +Managed to get a coredump. Coredumps usually tell me nothing but maybe someone here can find something useful in there... + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1873032 b/results/classifier/118/graphic/1873032 new file mode 100644 index 000000000..a2351eae2 --- /dev/null +++ b/results/classifier/118/graphic/1873032 @@ -0,0 +1,62 @@ +graphic: 0.813 +virtual: 0.787 +architecture: 0.745 +x86: 0.681 +performance: 0.619 +device: 0.600 +network: 0.533 +boot: 0.483 +files: 0.481 +socket: 0.455 +PID: 0.435 +mistranslation: 0.431 +semantic: 0.431 +VMM: 0.426 +vnc: 0.423 +ppc: 0.421 +debug: 0.413 +user-level: 0.411 +register: 0.402 +permissions: 0.388 +assembly: 0.370 +hypervisor: 0.368 +arm: 0.353 +risc-v: 0.350 +KVM: 0.307 +kernel: 0.277 +TCG: 0.261 +peripherals: 0.189 +i386: 0.182 + +After upgrade qemu to 5.0.0-0.3.rc2.fc33 the virtual machine with Windows 10 after a while starts to work very slowly + +Description of problem: + +After upgrade qemu to 5.0.0-0.3.rc2.fc33 the virtual machine with Windows 10 after a while starts to work very slowly + +I created the virtual machine with Windows 10 with the following config: +- 1 CPU +- 2GB RAM +- With network access + +I launch there a web browser there with flash content. +And usually, the system (Windows 10) does not work there for more than an hour. +When the system starts to work very slowly it doesn't respond to "Reboot" and "Shut Down" commands. Only works "Force Reset" and "Force Off". But when I reboot the system with "Force Reset" it usually stuck at boot at the Windows splash screen. https://imgur.com/yGyacDG + +The last version of qemu which not contain this issue is 5.0.0-0.2.rc0.fc33 + + + +When VM starts work very slowly System interrupts in Windows Task Manager eats up 99% of all CPU resources. + + +Please try this patch series: https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg02728.html + +Unofficial x86_64 build of v5.0.0 with those 2 patches for Arch is here: [1]. + +[1] https://download.opensuse.org/repositories/home:/post-factum/Arch/x86_64/ + +I confirm that with patches https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg02728.html Win 10 in QEMU working already more than 24 hours without issue. + +The patches mentioned in the previous comments have been released with QEMU v5.1, so I'm marking this bug as fixed now. If you still have problems, please open a new ticket. + diff --git a/results/classifier/118/graphic/1874 b/results/classifier/118/graphic/1874 new file mode 100644 index 000000000..948ae7d6f --- /dev/null +++ b/results/classifier/118/graphic/1874 @@ -0,0 +1,47 @@ +graphic: 0.990 +virtual: 0.971 +arm: 0.969 +semantic: 0.932 +device: 0.916 +architecture: 0.903 +ppc: 0.902 +x86: 0.822 +hypervisor: 0.816 +PID: 0.811 +peripherals: 0.790 +performance: 0.768 +network: 0.707 +socket: 0.700 +register: 0.683 +user-level: 0.682 +VMM: 0.677 +vnc: 0.673 +TCG: 0.662 +files: 0.660 +permissions: 0.625 +mistranslation: 0.619 +boot: 0.581 +debug: 0.574 +risc-v: 0.527 +kernel: 0.494 +i386: 0.348 +assembly: 0.233 +KVM: 0.101 + +QGA：Whether arm windows VMS are supported？ +Description of problem: +Whether qga can be used within an arm windows virtual machine? + +Windows reports an error (Failed to pCatalog->InstallComponent.(Error: 80110401) Errors occurred accessing one or more objects - the ErrorInfo collection may have more detail) when I try to install msi. Windows reports a warning(Catalog Event ID 5488: Unable to load DLL qga-vss.dll) (Unable to validate DLL entry points) in Event Viewer. + +I get msi from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-qemu-ga/qemu-ga-win-105.0.2-1.el9/qemu-ga-x86_64.msi +Either gqa does not support ARM or this msi is only for X86 architecture? + + + + +Steps to reproduce: +1. Start arm windows 11 vm. +2. Install qemu guest agent. +Additional information: + diff --git a/results/classifier/118/graphic/1875 b/results/classifier/118/graphic/1875 new file mode 100644 index 000000000..09f527bdf --- /dev/null +++ b/results/classifier/118/graphic/1875 @@ -0,0 +1,39 @@ +graphic: 0.908 +device: 0.591 +x86: 0.462 +performance: 0.443 +semantic: 0.339 +mistranslation: 0.253 +debug: 0.235 +virtual: 0.158 +i386: 0.094 +peripherals: 0.078 +user-level: 0.057 +boot: 0.055 +architecture: 0.053 +risc-v: 0.032 +ppc: 0.028 +vnc: 0.027 +network: 0.023 +arm: 0.023 +hypervisor: 0.010 +VMM: 0.007 +TCG: 0.005 +kernel: 0.005 +assembly: 0.005 +register: 0.004 +permissions: 0.003 +socket: 0.003 +files: 0.002 +PID: 0.001 +KVM: 0.000 + +qemu-system-x86_64: warning: no scancode found for keysym 65483 +Description of problem: +qemu-system-x86_64: warning: no scancode found for keysym 65483 + +I'm hoping this is something that could easily be added to qemu, rather than a limitation of windows: + +I want to bind F14 to an arbitrary key, in this case `keycode 148 = XF86Calculator`, but it's not happening, and qemu is giving the error: `qemu-system-x86_64: warning: no scancode found for keysym 65483` + +`xmodmap -e "keycode 148 = F14 F14 F14 F14 F14"` Executes with no error, and xev correctly shows as F14 pressed/released, but a windows 10 VM started afterwards cannot recognise this bind. diff --git a/results/classifier/118/graphic/1877526 b/results/classifier/118/graphic/1877526 new file mode 100644 index 000000000..bff8ec966 --- /dev/null +++ b/results/classifier/118/graphic/1877526 @@ -0,0 +1,103 @@ +graphic: 0.881 +KVM: 0.850 +ppc: 0.836 +peripherals: 0.836 +permissions: 0.806 +hypervisor: 0.805 +semantic: 0.793 +register: 0.783 +mistranslation: 0.764 +PID: 0.762 +risc-v: 0.747 +x86: 0.720 +device: 0.699 +debug: 0.696 +VMM: 0.694 +user-level: 0.687 +performance: 0.676 +TCG: 0.670 +virtual: 0.650 +architecture: 0.645 +socket: 0.640 +vnc: 0.628 +arm: 0.608 +assembly: 0.579 +files: 0.555 +boot: 0.548 +i386: 0.519 +network: 0.460 +kernel: 0.453 + +KVM internal crash + +Hi, +I am new to this. (apologies if I miss something) + +I see the following error when I run an application on my QEMU based VM running ubuntu linux: + +Code=4d 39 c8 7f 64 0f 1f 40 00 4d 8d 40 80 49 81 f8 80 00 00 00 <66> 0f 7f 07 66 0f 7f 47 10 66 0f 7f 47 20 66 0f 7f 47 30 +66 0f 7f 47 40 66 0f 7f 47 50 66 +KVM internal error. Suberror: 1 +emulation failure +RAX=00007fffeb85a000 RBX=00000000069ee400 RCX=0000000000000000 RDX=0000000000000000 +RSI=0000000000000000 RDI=00007fffeb85a000 RBP=00007fffffff9570 RSP=00007fffffff9548 +R8 =0000000000000f80 R9 =0000000001000000 R10=0000000000000000 R11=0000003694e83f3a +R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000006b75350 +RIP=0000003694e8443b RFL=00010206 [-----P-] CPL=3 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 ffffffff 00000000 +CS =0033 0000000000000000 ffffffff 00a0fb00 DPL=3 CS64 [-RA] +SS =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA] +DS =0000 0000000000000000 ffffffff 00000000 +FS =0000 00007ffff45b5720 ffffffff 00000000 +GS =0000 0000000000000000 ffffffff 00000000 +LDT=0000 0000000000000000 ffffffff 00000000 +TR =0040 ffff88047fd13140 00002087 00008b00 DPL=0 TSS64-busy +GDT= ffff88047fd04000 0000007f +IDT= ffffffffff57c000 00000fff +CR0=80050033 CR2=00007ffff7ff4000 CR3=000000046cb38000 CR4=000006e0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 + +This occurs with qemu-kvm version(host m/c has RHEL 6.6) : +Name : qemu-kvm +Arch : x86_64 +Epoch : 2 +Version : 0.12.1.2 +Release : 2.506.el6_10.7 + +I have another m/c with RHEL 7.5, and the same test case passes with the 1.5.3 version. +yum info qemu-kvm +Name : qemu-kvm +Arch : x86_64 +Epoch : 10 +Version : 1.5.3 + + +How do I investigate this? +I would need to patch up the qemu-kvm on the host to get this fixed, I think. + +Please let me know if I need to provide more info, (and what?) + +Regards, +Prashant + +RHEL 6.6 and qemu-kvm 0.12 are *very* old, can't you update the machine to a newer version? At least RHEL 6.10, or even better RHEL 7 or 8? + +Unfortunately, I am not is a position to upgraded (due to various reasons). +The case passes with RHEL 7.3, so, but I need to find the issue RHEL 6.6. (to be sure I don't the bug +is NOT in my code). + +Is there a way that I can keep patching the KVM up to the newer versions, and then, find the version where the issue is fixed. + +May be that helps. + +And how do analyse this error info. + +Regards, +Prashant + + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1878 b/results/classifier/118/graphic/1878 new file mode 100644 index 000000000..abc446927 --- /dev/null +++ b/results/classifier/118/graphic/1878 @@ -0,0 +1,59 @@ +graphic: 0.927 +kernel: 0.885 +device: 0.848 +architecture: 0.836 +performance: 0.816 +files: 0.805 +arm: 0.786 +semantic: 0.754 +network: 0.672 +debug: 0.671 +socket: 0.650 +permissions: 0.621 +user-level: 0.607 +register: 0.593 +peripherals: 0.579 +PID: 0.571 +mistranslation: 0.563 +ppc: 0.514 +boot: 0.500 +vnc: 0.498 +assembly: 0.480 +x86: 0.454 +risc-v: 0.443 +hypervisor: 0.413 +VMM: 0.333 +i386: 0.232 +KVM: 0.222 +TCG: 0.221 +virtual: 0.144 + +QEMU doesn't implement ARMv4/v5 legacy SCTLR.U==0 load-and-rotate unaligned access handling +Description of problem: +**ldr r7, \[r0, r1\]** works differently on real device and QEMU. Probably all **ldr Rd, \[Rs\]** commands works wrongly in QEMU with Raspberry Pi emulation. +Steps to reproduce: +1. Launch the attached software **kernel_qemu.img** in QEMU. +2. Launch the attached software **kerenel.img** on real Raspberry Pi 1B+. +3. Look at the r7. It contains different data. +Additional information: +**kernel_qemu.img** and **kerenel.img** are the same program. It just compiled with different origins - 0x8000 for real device and 0x10000 for QEMU. But code inside the program works at the same addresses. + +r0 = 0x183a4 + +r1 = 0x817 + +**\[r0, r1\]** points to byte 0x42 in memory with such data: + +**0x80 0x15 0x22 \[0x42\] 0x03 0x21 0x87** + +After **ldr r7, \[r0, r1\]** execution real device puts to r7: **0x22158042** + +After **ldr r7, \[r0, r1\]** execution QEMU puts to r7: **0x87210342** + +QEMU: + + + +Real Raspberry Pi 1B+:  + +[kernel_qemu.img](/uploads/ae6a7490660569d5fe56adc9f4dde85d/kernel_qemu.img) [kernel.img](/uploads/48c94a66370c1fe8720fe89603c45c7b/kernel.img) diff --git a/results/classifier/118/graphic/1878043 b/results/classifier/118/graphic/1878043 new file mode 100644 index 000000000..485ccd616 --- /dev/null +++ b/results/classifier/118/graphic/1878043 @@ -0,0 +1,117 @@ +graphic: 0.888 +risc-v: 0.864 +register: 0.861 +mistranslation: 0.845 +x86: 0.841 +user-level: 0.837 +TCG: 0.832 +device: 0.828 +KVM: 0.825 +ppc: 0.822 +peripherals: 0.817 +i386: 0.809 +virtual: 0.806 +hypervisor: 0.804 +arm: 0.797 +VMM: 0.794 +performance: 0.793 +architecture: 0.792 +permissions: 0.787 +files: 0.778 +vnc: 0.766 +semantic: 0.764 +network: 0.750 +assembly: 0.749 +boot: 0.729 +PID: 0.723 +debug: 0.706 +socket: 0.689 +kernel: 0.685 + +memcpy param-overlap in Slirp ip_stripoptions through e1000e + +Hello, +While fuzzing, I found an input that triggers an overlapping memcpy (caught by AddressSanitizer). +Overlapping memcpys are undefined behavior according to the POSIX and C standards, and can lead to bugs. + +==16666==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x625000264940,0x62500026699a) and [0x625000264948, 0x6250002669a2) overlap + #0 0x5622d7b6a3d4 in __asan_memcpy (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x96c3d4) + #1 0x5622d896a2d2 in ip_stripoptions /home/alxndr/Development/qemu/slirp/src/ip_input.c:457:5 + #2 0x5622d8963378 in udp_input /home/alxndr/Development/qemu/slirp/src/udp.c:86:9 + #3 0x5622d89351ea in slirp_input /home/alxndr/Development/qemu/slirp/src/slirp.c:840:13 + #4 0x5622d852e162 in net_slirp_receive /home/alxndr/Development/qemu/net/slirp.c:126:5 + #5 0x5622d8515851 in nc_sendv_compat /home/alxndr/Development/qemu/net/net.c:700:15 + #6 0x5622d8515851 in qemu_deliver_packet_iov /home/alxndr/Development/qemu/net/net.c:728:15 + #7 0x5622d851786d in qemu_net_queue_deliver_iov /home/alxndr/Development/qemu/net/queue.c:179:11 + #8 0x5622d851786d in qemu_net_queue_send_iov /home/alxndr/Development/qemu/net/queue.c:224:11 + #9 0x5622d851b1c1 in net_hub_receive_iov /home/alxndr/Development/qemu/net/hub.c:74:9 + #10 0x5622d851b1c1 in net_hub_port_receive_iov /home/alxndr/Development/qemu/net/hub.c:125:12 + #11 0x5622d851572b in qemu_deliver_packet_iov /home/alxndr/Development/qemu/net/net.c:726:15 + #12 0x5622d851786d in qemu_net_queue_deliver_iov /home/alxndr/Development/qemu/net/queue.c:179:11 + #13 0x5622d851786d in qemu_net_queue_send_iov /home/alxndr/Development/qemu/net/queue.c:224:11 + #14 0x5622d828bf87 in net_tx_pkt_sendv /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:546:9 + #15 0x5622d828bf87 in net_tx_pkt_send /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:620:9 + #16 0x5622d82b5f22 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/hw/net/e1000e_core.c:666:16 + #17 0x5622d82b5f22 in e1000e_process_tx_desc /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743:17 + #18 0x5622d82b5f22 in e1000e_start_xmit /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9 + #19 0x5622d82b2be0 in e1000e_set_tdt /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451:9 + #20 0x5622d82a30fc in e1000e_core_write /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261:9 + #21 0x5622d7c9e336 in memory_region_write_accessor /home/alxndr/Development/qemu/memory.c:483:5 + #22 0x5622d7c9dcdf in access_with_adjusted_size /home/alxndr/Development/qemu/memory.c:544:18 + #23 0x5622d7c9dcdf in memory_region_dispatch_write /home/alxndr/Development/qemu/memory.c:1476:16 + #24 0x5622d7bb31d3 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3137:23 + #25 0x5622d7babb97 in flatview_write /home/alxndr/Development/qemu/exec.c:3177:14 + #26 0x5622d7babb97 in address_space_write /home/alxndr/Development/qemu/exec.c:3268:18 + +0x625000264940 is located 64 bytes inside of 8354-byte region [0x625000264900,0x6250002669a2) +allocated by thread T0 here: + #0 0x5622d7b6b06d in malloc (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x96d06d) + #1 0x7f724b932500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) + +0x625000264948 is located 72 bytes inside of 8354-byte region [0x625000264900,0x6250002669a2) +allocated by thread T0 here: + #0 0x5622d7b6b06d in malloc (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x96d06d) + #1 0x7f724b932500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) + +I can reproduce it in qemu 5.0 built with --enable-sanitizers using: +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -accel qtest -qtest stdio -nographic -monitor none -serial none +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe1069000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fb20 +write 0xe1069100 0xe 0xff810000000000008420f9e10019 +write 0x820b 0xc 0x080047bb0c02e10000004011 +write 0xe1020403 0x36 0xb700000000e1000f009006e100000000625c5e0000b700000000e1000f009006e100000000625c5e0000b700000000e1000f009006e1 +EOF + +I also attached the trace to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -M pc-q35-5.0 -accel qtest -qtest stdio -nographic -monitor none -serial none < attachment + +Please let me know if I can provide any further info. +-Alex + + + +Created patch and merge request in upstream libslirp: + +https://gitlab.freedesktop.org/dgilbert/libslirp/-/commit/d620bac888923524f8b8407dbf35f6d2b3b7ddb2 + +Committed in upstream libslirp: + +commit d620bac888923524f8b8407dbf35f6d2b3b7ddb2 (origin/lp1878043, lp1878043) +Author: Dr. David Alan Gilbert <email address hidden> +Date: Fri Jul 17 18:17:41 2020 +0100 + + ip_stripoptions use memmove + + +Released with QEMU v5.2.0. + diff --git a/results/classifier/118/graphic/1879 b/results/classifier/118/graphic/1879 new file mode 100644 index 000000000..2ec0327f5 --- /dev/null +++ b/results/classifier/118/graphic/1879 @@ -0,0 +1,39 @@ +architecture: 0.947 +arm: 0.932 +graphic: 0.920 +virtual: 0.912 +files: 0.883 +device: 0.865 +VMM: 0.848 +risc-v: 0.648 +debug: 0.642 +vnc: 0.637 +semantic: 0.559 +PID: 0.524 +boot: 0.488 +register: 0.484 +user-level: 0.360 +hypervisor: 0.357 +performance: 0.352 +kernel: 0.323 +TCG: 0.318 +mistranslation: 0.302 +ppc: 0.293 +permissions: 0.277 +network: 0.205 +assembly: 0.085 +socket: 0.074 +peripherals: 0.073 +KVM: 0.054 +i386: 0.004 +x86: 0.002 + +ARM Cortex-A15 Emulation Not Working +Description of problem: +I want to make a VM with Windows RT 8.1 but it fails because it can't find a file for the to-emulate ARM CPU. +Steps to reproduce: +1. Use virt-manager to make a VM with the ARM architecture. +2. Make sure the emulated CPU is an ARM Cortex-A15. +3. Try installing and making the VM, it will fail with the error. +Additional information: + diff --git a/results/classifier/118/graphic/1882 b/results/classifier/118/graphic/1882 new file mode 100644 index 000000000..a82a4e64a --- /dev/null +++ b/results/classifier/118/graphic/1882 @@ -0,0 +1,39 @@ +graphic: 0.972 +performance: 0.909 +device: 0.854 +socket: 0.735 +network: 0.732 +semantic: 0.704 +vnc: 0.664 +architecture: 0.535 +PID: 0.515 +mistranslation: 0.487 +kernel: 0.453 +boot: 0.450 +debug: 0.375 +TCG: 0.371 +peripherals: 0.358 +ppc: 0.355 +permissions: 0.347 +arm: 0.313 +files: 0.274 +register: 0.274 +user-level: 0.255 +hypervisor: 0.238 +VMM: 0.227 +risc-v: 0.223 +virtual: 0.144 +assembly: 0.072 +x86: 0.036 +i386: 0.017 +KVM: 0.014 + +Test suite hangs on FreeBSD 13.2 +Description of problem: +The 80 minute timeout for the x64-freebsd-13-build CI job is insufficient: +https://gitlab.com/qemu-project/qemu/-/jobs/5058610599 + +``` +672/832 qemu:block / io-qcow2-041 OK 39.77s 1 subtests passed +Timed out! +``` diff --git a/results/classifier/118/graphic/1883 b/results/classifier/118/graphic/1883 new file mode 100644 index 000000000..9f187b105 --- /dev/null +++ b/results/classifier/118/graphic/1883 @@ -0,0 +1,36 @@ +graphic: 0.956 +semantic: 0.724 +risc-v: 0.571 +device: 0.551 +mistranslation: 0.471 +performance: 0.380 +architecture: 0.218 +network: 0.211 +PID: 0.187 +vnc: 0.170 +TCG: 0.152 +debug: 0.146 +arm: 0.117 +x86: 0.094 +user-level: 0.091 +register: 0.089 +i386: 0.075 +files: 0.073 +virtual: 0.069 +permissions: 0.059 +socket: 0.044 +ppc: 0.041 +peripherals: 0.041 +boot: 0.038 +VMM: 0.034 +hypervisor: 0.024 +assembly: 0.019 +kernel: 0.007 +KVM: 0.003 + +riscv64-debian-cross-container CI job fails +Description of problem: +The riscv64-debian-cross-container job is allowed to fail and has been failing for some time. If it fails all the time then running it is a waste of electricity and the test should be disabled. Or maybe someone familiar with the test can rectify things and get it passing again. Either way, it's time for someone familiar with the test to review it. + +Here it a recent CI failure: +https://gitlab.com/qemu-project/qemu/-/jobs/5058610458 diff --git a/results/classifier/118/graphic/1884017 b/results/classifier/118/graphic/1884017 new file mode 100644 index 000000000..3dcb1ca7a --- /dev/null +++ b/results/classifier/118/graphic/1884017 @@ -0,0 +1,81 @@ +i386: 0.970 +graphic: 0.921 +user-level: 0.897 +x86: 0.872 +device: 0.835 +peripherals: 0.827 +architecture: 0.797 +ppc: 0.791 +kernel: 0.771 +permissions: 0.766 +network: 0.759 +performance: 0.757 +hypervisor: 0.756 +files: 0.738 +mistranslation: 0.724 +semantic: 0.705 +PID: 0.673 +debug: 0.670 +socket: 0.652 +TCG: 0.652 +vnc: 0.652 +register: 0.649 +assembly: 0.645 +risc-v: 0.641 +arm: 0.639 +VMM: 0.605 +boot: 0.592 +KVM: 0.577 +virtual: 0.512 + +Intermittently erratic mouse under Windows 95 + +The mouse works fine maybe 75-80% of the time, but intermittently (every 20-30 seconds or so), moving the mouse will cause the pointer to fly around the screen at high speed, usually colliding with the edges, and much more problematically, click all the mouse buttons at random, even if you are not clicking. This causes random objects on the screen to be clicked and dragged around, rendering the system generally unusable. + +I don't know if this is related to #1785485 - it happens even if you never use the scroll wheel. + +qemu version: 5.0.0 (openSUSE Tumbleweed) + +Launch command line: qemu-system-i386 -hda win95.qcow2 -cpu pentium2 -m 16 -vga cirrus -soundhw sb16 -nic user,model=pcnet -rtc base=localtime + +OS version: Windows 95 4.00.950 C + +I have made the disk image available here: https://home.gloveraoki.me/share/win95.qcow2.lz + +Setup notes: In order to make Windows 95 detect the system devices correctly, after first install you must change the driver for "Plug and Play BIOS" to "PCI bus". I have already done this in the above image. + +Weirdly, this problem doesn't occur when running qemu on macOS (10.15.5). It only happens on my PC running openSUSE Tumbleweed. + +However, even on that PC, it only affects Windows 95, and not Windows 98, or other operating systems. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1885 b/results/classifier/118/graphic/1885 new file mode 100644 index 000000000..1f010f326 --- /dev/null +++ b/results/classifier/118/graphic/1885 @@ -0,0 +1,54 @@ +graphic: 0.874 +device: 0.852 +architecture: 0.825 +kernel: 0.818 +boot: 0.816 +PID: 0.787 +performance: 0.756 +ppc: 0.706 +arm: 0.665 +files: 0.653 +register: 0.647 +permissions: 0.609 +network: 0.600 +VMM: 0.592 +socket: 0.576 +mistranslation: 0.566 +risc-v: 0.563 +semantic: 0.543 +TCG: 0.540 +vnc: 0.537 +debug: 0.527 +virtual: 0.518 +peripherals: 0.416 +x86: 0.382 +user-level: 0.381 +hypervisor: 0.340 +i386: 0.302 +assembly: 0.276 +KVM: 0.154 + +mipsel malta machine is broken in avocado console tests +Description of problem: +As noted in #1884 we see failures of the boot_linux_console.py test. Unlikely other avocado failures, these ones are consistent and reproduce locally with 100% success + +``` +./configure --target-list=mipsel-softmmu +make -j 20 +cd build +./pyvenv/bin/python3 -B -m avocado --show=app run --job-results-dir=./tests/results -t arch:mipsel --failfast tests/avocado/boot_linux_console.py:BootLinuxConsole.test_mips_malta32el_nanomips_4k +``` + +This test will reliably fail with a timeout waiting for console output. + +Attempting to run the QEMU command manually + +``` +$ ./qemu-system-mipsel -display none -vga none -machine malta -chardev stdio,id=console -serial chardev:console -cpu I7200 -no-reboot -kernel /home/berrange/src/virt/qemu/build/tests/results/job-2023-09-13T17.14-77de093/test-results/tmp_dir520smana/1-tests_avocado_boot_linux_console.py_BootLinuxConsole.test_mips_malta32el_nanomips_4kkernel -append 'printk.time=0 mem=256m@@0x0 console=ttyS0' +``` + +results in no serial console output at all. + +IMHO either the MIPS malta machine has had a regression, or the kernel we're downloading for testing has had a regression. +Additional information: + diff --git a/results/classifier/118/graphic/1886285 b/results/classifier/118/graphic/1886285 new file mode 100644 index 000000000..aa53499fd --- /dev/null +++ b/results/classifier/118/graphic/1886285 @@ -0,0 +1,71 @@ +graphic: 0.805 +user-level: 0.772 +semantic: 0.683 +device: 0.663 +files: 0.651 +mistranslation: 0.643 +network: 0.641 +architecture: 0.639 +permissions: 0.601 +debug: 0.589 +peripherals: 0.589 +PID: 0.583 +performance: 0.583 +hypervisor: 0.566 +ppc: 0.543 +register: 0.506 +VMM: 0.501 +socket: 0.491 +vnc: 0.479 +x86: 0.466 +virtual: 0.461 +TCG: 0.450 +risc-v: 0.448 +i386: 0.445 +KVM: 0.440 +assembly: 0.435 +kernel: 0.433 +arm: 0.414 +boot: 0.412 + +Provide SMB option to support Windows 2000 + +As of SAMBA 4.11 (https://www.samba.org/samba/history/samba-4.11.0.html), SMB1 is disabled by default (and may be removed in the future). This breaks SMB shares with Windows 2000 guests. + +Adding the following line to smb.conf fixes this: + +min protocol = NT1 + +I would propose that an option be added to add this line to smb.conf to support these legacy operating systems. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1887306 b/results/classifier/118/graphic/1887306 new file mode 100644 index 000000000..7cad8298d --- /dev/null +++ b/results/classifier/118/graphic/1887306 @@ -0,0 +1,127 @@ +graphic: 0.923 +semantic: 0.901 +performance: 0.900 +debug: 0.895 +virtual: 0.893 +user-level: 0.883 +peripherals: 0.882 +permissions: 0.879 +hypervisor: 0.872 +ppc: 0.869 +assembly: 0.861 +risc-v: 0.858 +mistranslation: 0.850 +register: 0.847 +VMM: 0.829 +architecture: 0.828 +socket: 0.828 +PID: 0.827 +TCG: 0.827 +device: 0.810 +arm: 0.806 +boot: 0.799 +files: 0.798 +kernel: 0.796 +network: 0.791 +x86: 0.752 +vnc: 0.746 +KVM: 0.742 +i386: 0.380 + +qemu-user deadlocks when forked in a multithreaded process + +The following program (also attached) deadlocks when run under QEMU user on Linux. + +#include <pthread.h> +#include <stdio.h> +#include <stdlib.h> +#include <sys/types.h> +#include <sys/wait.h> +#include <unistd.h> + +#define NUM_THREADS 100 +#define NUM_FORKS 10 + +pthread_barrier_t barrier; + +void *t(void *arg) { + for (int i = 0; i < NUM_FORKS; i++) { + pid_t pid = fork(); + if (pid < 0) + abort(); + if (!pid) + _exit(0); + if (waitpid(pid, NULL, 0) < 0) + abort(); + } + //pthread_barrier_wait(&barrier); + return NULL; +} + +int main(void) { + pthread_barrier_init(&barrier, NULL, NUM_THREADS); + pthread_t ts[NUM_THREADS]; + for (size_t i = 0; i < NUM_THREADS; i++) { + if (pthread_create(&ts[i], NULL, t, NULL)) + abort(); + } + for (size_t i = 0; i < NUM_THREADS; i++) { + pthread_join(ts[i], NULL); + } + printf("Done: %d\n", getpid()); + return 0; +} + +To reproduce: +$ gcc test.c -pthread +$ while qemu-x86_64 ./a.out; do :; done + +(Be careful, Ctrl-C/SIGINT doesn't kill the deadlocked child). + +Larger values of NUM_THREADS/NUM_FORKS lead to more often deadlocks. With the values above it often deadlocks on the first try on my machine. When it deadlocks, there is a child qemu process with two threads which is waited upon by one of the worker threads of the parent. + +I tried to avoid the deadlock by serializing fork() with a mutex, but it didn't help. However, ensuring that no thread exits until all forks are done (by adding a barrier to t()) does seem to help, at least, the program above could run for a half an hour until I terminated it. + +Tested on QEMU 5.0.0, 4.2.0 and 2.11.1, with x86_64 and AArch64 linux-user targets. + + + +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. + + +Still reproduces with QEMU 6.0.0. + + +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/358 + + diff --git a/results/classifier/118/graphic/1888467 b/results/classifier/118/graphic/1888467 new file mode 100644 index 000000000..cf9c4827a --- /dev/null +++ b/results/classifier/118/graphic/1888467 @@ -0,0 +1,106 @@ +graphic: 0.848 +virtual: 0.816 +performance: 0.808 +semantic: 0.803 +register: 0.795 +permissions: 0.787 +user-level: 0.787 +device: 0.751 +debug: 0.749 +PID: 0.745 +files: 0.731 +architecture: 0.729 +assembly: 0.723 +arm: 0.718 +hypervisor: 0.713 +ppc: 0.699 +network: 0.681 +peripherals: 0.647 +boot: 0.647 +TCG: 0.638 +risc-v: 0.636 +kernel: 0.636 +KVM: 0.632 +mistranslation: 0.614 +x86: 0.605 +vnc: 0.589 +socket: 0.577 +VMM: 0.566 +i386: 0.435 + +qemu-img http convert bug + +Hello, Why the file sizes of http conversion and local conversion are inconsistent? + +Use the http method of qemu-img for conversion. The size of some formats after conversion is different from the local method of qemu-img. Such as vhd, vdi. qcow2 and vmdk are normal。 +My image size is 40 G, raw format. + +The source is the same file, but the access method is different +http method of qemu-img： qemu-img convert -f raw -O vdi http://xxx xxx.vdi（19G，after conversion） +local method of qemu-img： qemu-img convert -f raw -O vdi xxx.raw xxx.vdi（3G，after conversion） + +thank you + +Hi, + +What exactly do you mean by “file size”? The file length (as reported by ls -l) or the bytes used on disk (reported as “disk size” by qemu-img, or by du -B1)? + +You say that qcow2 and vmdk are normal – do you mean as input or as output formats? + +One thing that comes to my mind is that from http, we have no way of inquiring about holes in the source file, so we have to scan the file for ranges that are zero, which may not be optimal. OTOH, the default minimum-zero length is 4 kB, which should basically be the granularity at which filesystems can record and report holes, too. +(And if that’s the problem, it should present itself regardless of the output format.) + +Can you paste the output for “qemu-img map” on your source file somewhere (the local one), or is that too long? + +first, what I said "file size" is file length as reported by ls -l?field.comment=first, what I said "file size" is file length as reported by ls -l. + +The following attachment shows the size of the same source file after different conversion methods， + +http -> local: qemu-img convert -f raw -O vdi localfile localfile1 +local -> local: qemu-img convert -f raw -O vdi localfile localfile2 +localfile1's size is different from localfile2 + +secondly, the conversion of qcow2 and vmdk is normal. +http -> local: qemu-img convert -f raw -O qcow2 localfile localfile1 +local -> local: qemu-img convert -f raw -O qcow2 localfile localfile2 +localfile1's size is the same size as localfile2 + +OK, that’s interesting. To be honest, I have no idea. I’ll keep this in mind and I’ll try to play around with it, but I can’t promise anything. + +hello, I have an other question。 +Why does qemu-img support http reader mode but not http writer mode? +think you. + +Because nobody has implemented it so far. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1889 b/results/classifier/118/graphic/1889 new file mode 100644 index 000000000..f7ccd666c --- /dev/null +++ b/results/classifier/118/graphic/1889 @@ -0,0 +1,77 @@ +graphic: 0.925 +performance: 0.898 +boot: 0.838 +socket: 0.768 +device: 0.752 +PID: 0.705 +architecture: 0.647 +vnc: 0.595 +virtual: 0.570 +kernel: 0.556 +semantic: 0.537 +x86: 0.534 +network: 0.531 +peripherals: 0.523 +hypervisor: 0.516 +ppc: 0.513 +risc-v: 0.452 +i386: 0.445 +VMM: 0.434 +arm: 0.396 +permissions: 0.379 +user-level: 0.352 +register: 0.319 +files: 0.317 +debug: 0.311 +assembly: 0.300 +TCG: 0.282 +mistranslation: 0.249 +KVM: 0.204 + +IO delays on live migration lv initialization +Description of problem: +Hi, + +When I live migrate a VM via Proxmox and the destination is an LVM thin pool I see that at the start of copying the disk it's first initialized. + +This leads the thin volume to be directly 100% allocated which needs to be discarded afterwards. Not ideal but .... + +The more annoying thing is that this initialization step used 100% of disk IO. In iotop I see it writing over 1000MB/sec. The nasty side effect is that other VM's on that host are negatively affected. It's not completely locked up, I can ssh in and look around, but storage intensive things see more delay. With e.g. http requests timing out. And even a simple ls command could take 10+ seconds which is normally instant. + + +I've previously reported it on the [proxmox forum](https://forum.proxmox.com/threads/io-delays-on-live-migration-lv-initialization.132296/#post-582050) but the call was made that this is behavior from Qemu. + +> The zeroing happens, because of what QEMU does when the discard option is enabled: + + +When I disable discard for the VM disk I can see that it's not pre-initialized during migration, but not having that defeats the purpose of having an lvm thin pool. + +For the (disk) migration itself I can set a bandwidth limit ... could we do something similar for initialization? + + +Even better would be to not initialize at all when using LVM thin. As far as I understand it the new blocks allocated by lvm thin should always be empty. +Steps to reproduce: +1. Migrate a vm with a large disk +2. look in iotop on the new host, would be see more write IO then the network could handle.. just before the disk content is transferred. +3. look in another VM on the destination host, reading from disk would be significantly slower then normal. +Additional information: +An example VM config +``` +agent: 1,fstrim_cloned_disks=1 +balloon: 512 +bootdisk: scsi0 +cores: 6 +ide2: none,media=cdrom +memory: 8196 +name: ... +net0: virtio=...,bridge=... +numa: 0 +onboot: 1 +ostype: l26 +scsi0: thin_pool_hwraid:vm-301-disk-0,discard=on,format=raw,size=16192M +scsi1: thin_pool_hwraid:vm-301-disk-1,discard=on,format=raw,size=26G +scsihw: virtio-scsi-pci +serial0: socket +smbios1: uuid=... +sockets: 1 +``` diff --git a/results/classifier/118/graphic/1890370 b/results/classifier/118/graphic/1890370 new file mode 100644 index 000000000..e23d79715 --- /dev/null +++ b/results/classifier/118/graphic/1890370 @@ -0,0 +1,105 @@ +graphic: 0.881 +register: 0.848 +performance: 0.837 +semantic: 0.827 +permissions: 0.827 +risc-v: 0.816 +architecture: 0.812 +virtual: 0.803 +arm: 0.798 +assembly: 0.793 +device: 0.781 +peripherals: 0.750 +debug: 0.750 +files: 0.744 +mistranslation: 0.743 +PID: 0.742 +user-level: 0.739 +TCG: 0.727 +vnc: 0.726 +socket: 0.720 +network: 0.715 +x86: 0.703 +ppc: 0.698 +VMM: 0.698 +kernel: 0.667 +hypervisor: 0.665 +boot: 0.646 +i386: 0.567 +KVM: 0.548 + +Segfault in artist vram_bit_write + +Hello, +Reproducer: + +cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ +-qtest stdio -accel qtest +writeq 0xf810049f 0xffffffffffffffff +writew 0xf8118001 0xff7c +writew 0xf8118000 0x8300 +writeq 0xf81005fb 0x5c18006400189e +EOF + + +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /hw/display/artist.c:402:17 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==23157==ERROR: AddressSanitizer: SEGV on unknown address 0x7f17563fffff (pc 0x560ce3ad742c bp 0x7ffe310c62e0 sp 0x7ffe310c5a60 T0) +==23157==The signal is caused by a WRITE memory access. + #0 0x560ce3ad742c in vram_bit_write /hw/display/artist.c:402:43 + #1 0x560ce3acf2ab in artist_reg_write /hw/display/artist.c:892:9 + #2 0x560ce31c37a3 in memory_region_write_accessor /softmmu/memory.c:483:5 + #3 0x560ce31c2adc in access_with_adjusted_size /softmmu/memory.c:539:18 + #4 0x560ce31c0873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 + #5 0x560ce286e056 in flatview_write_continue /exec.c:3176:23 + #6 0x560ce2856866 in flatview_write /exec.c:3216:14 + #7 0x560ce2856387 in address_space_write /exec.c:3308:18 + #8 0x560ce326a604 in qtest_process_command /softmmu/qtest.c:452:13 + #9 0x560ce3261c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 + #10 0x560ce3260895 in qtest_read /softmmu/qtest.c:722:5 + #11 0x560ce571d343 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #12 0x560ce571d4c7 in qemu_chr_be_write /chardev/char.c:200:9 + #13 0x560ce57317b3 in fd_chr_read /chardev/char-fd.c:68:9 + #14 0x560ce5885b74 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #15 0x7f1665259897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #16 0x560ce5c7da7b in glib_pollfds_poll /util/main-loop.c:217:9 + #17 0x560ce5c7b1ab in os_host_main_loop_wait /util/main-loop.c:240:5 + #18 0x560ce5c7ab44 in main_loop_wait /util/main-loop.c:516:11 + #19 0x560ce3282d00 in qemu_main_loop /softmmu/vl.c:1676:9 + #20 0x560ce58bd961 in main /softmmu/main.c:49:5 + #21 0x7f1663ddfe0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #22 0x560ce2761729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729) + + +With -trace artist\* + +[I 1596601002.853158] OPENED +[R +0.047035] writeq 0xf810049f 0xffffffffffffffff +24590@1596601002.900238:artist_reg_write 1 0x10049f <- 0xff +24590@1596601002.900258:artist_reg_write 4 0x1004a0 VRAM_IDX <- 0xffffffff +24590@1596601002.900269:artist_reg_write 2 0x1004a4 <- 0xffff +24590@1596601002.900280:artist_reg_write 1 0x1004a6 <- 0xff +OK +[S +0.047130] OK +[R +0.047159] writew 0xf8118001 0xff7c +24590@1596601002.900331:artist_reg_write 1 0x118001 CMAP_BM_ACCESS <- 0xff +24590@1596601002.900344:artist_reg_write 1 0x118002 CMAP_BM_ACCESS <- 0x7c +OK +[S +0.047194] OK +[R +0.047213] writew 0xf8118000 0x8300 +24590@1596601002.900383:artist_reg_write 2 0x118000 CMAP_BM_ACCESS <- 0x8300 +OK +[S +0.047231] OK +[R +0.047243] writeq 0xf81005fb 0x5c18006400189e +24590@1596601002.900410:artist_reg_write 1 0x1005fb <- 0x0 +24590@1596601002.900418:artist_reg_write 4 0x1005fc <- 0x5c180064 +24590@1596601002.900424:artist_reg_write 2 0x100600 VRAM_WRITE_INCR_X <- 0x18 +/home/alxndr/Development/qemu/general-fuzz/hw/display/artist.c:402:17: runtime error: store to misaligned address 0x7fd01d3fffff for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment +0x7fd01d3fffff: note: pointer points here +<memory cannot be printed> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/alxndr/Development/qemu/general-fuzz/hw/display/artist.c:402:17 in +AddressSanitizer:DEADLYSIGNAL + +-Alex + diff --git a/results/classifier/118/graphic/1890395 b/results/classifier/118/graphic/1890395 new file mode 100644 index 000000000..b91c0f6de --- /dev/null +++ b/results/classifier/118/graphic/1890395 @@ -0,0 +1,199 @@ +graphic: 0.925 +register: 0.919 +permissions: 0.907 +arm: 0.891 +mistranslation: 0.890 +semantic: 0.887 +device: 0.883 +performance: 0.883 +assembly: 0.866 +user-level: 0.862 +virtual: 0.854 +architecture: 0.841 +debug: 0.833 +KVM: 0.823 +PID: 0.818 +boot: 0.817 +socket: 0.814 +files: 0.809 +ppc: 0.787 +network: 0.786 +TCG: 0.781 +kernel: 0.778 +hypervisor: 0.776 +peripherals: 0.764 +VMM: 0.751 +vnc: 0.739 +x86: 0.711 +risc-v: 0.628 +i386: 0.564 + +qmp/hmp: crash if client closes socket too early + +Qemu crashes on qmp/hmp command if client closes connection before reading the whole response from the socket. + +Reproducer: + +1. Start arbitrary vm via qemu +2. Send e.g. hmp command 'info mem' +3. Abort before whole response came back + + +Stack Trace: + +Stack trace of thread 6493: +#0 0x0000559902fd2d30 object_get_class (qemu-system-x86_64) +#1 0x0000559903071020 qio_channel_create_watch (qemu-system-x86_64) +#2 0x000055990305f437 qemu_chr_fe_add_watch (qemu-system-x86_64) +#3 0x0000559902f7340d monitor_flush_locked (qemu-system-x86_64) +#4 0x0000559902f7360e monitor_flush_locked (qemu-system-x86_64) +#5 0x0000559902f74342 qmp_send_response (qemu-system-x86_64) +#6 0x0000559902f74409 monitor_qmp_respond (qemu-system-x86_64) +#7 0x0000559902f74bc0 monitor_qmp_bh_dispatcher (qemu-system-x86_64) +#8 0x00005599030c37be aio_bh_call (qemu-system-x86_64) +#9 0x00005599030c6dd0 aio_dispatch (qemu-system-x86_64) +#10 0x00005599030c369e aio_ctx_dispatch (qemu-system-x86_64) +#11 0x00007f5b6d37f417 g_main_context_dispatch (libglib-2.0.so.0) +#12 0x00005599030c5e0a glib_pollfds_poll (qemu-system-x86_64) +#13 0x0000559902dd75df main_loop (qemu-system-x86_64) +#14 0x0000559902c59f49 main (qemu-system-x86_64) +#15 0x00007f5b6bfeab97 __libc_start_main (libc.so.6) +#16 0x0000559902c5d38a _start (qemu-system-x86_64) + +#0 0x0000559902fd2d30 in object_get_class (obj=obj@entry=0x0) at ./qom/object.c:909 +#1 0x0000559903071020 in qio_channel_create_watch (ioc=0x0, condition=(G_IO_OUT | G_IO_HUP)) at ./io/channel.c:281 + klass = <optimized out> + __func__ = "qio_channel_create_watch" + ret = <optimized out> +#2 0x000055990305f437 in qemu_chr_fe_add_watch (be=be@entry=0x559905a7f460, cond=cond@entry=(G_IO_OUT | G_IO_HUP), func=func@entry=0x559902f734b0 <monitor_unblocked>, user_data=user_data@entry=0x559905a7f460) at ./chardev/char-fe.c:367 + s = 0x5599055782c0 + src = <optimized out> + tag = <optimized out> + __func__ = "qemu_chr_fe_add_watch" +#3 0x0000559902f7340d in monitor_flush_locked (mon=mon@entry=0x559905a7f460) at ./monitor/monitor.c:140 + rc = 219264 + len = 3865832 + buf = 0x7f5afc00e480 "{\"return\": \"ffff9eb480000000-ffff9eb480099000 ", '0' <repeats 11 times>, "99000 -rw\\r\\nffff9eb480099000-ffff9eb48009b000 ", '0' <repeats 12 times>, "2000 -r-\\r\\nffff9eb48009b000-ffff9eb486800000 0000000006765000 -rw\\r\\nffff9eb4868000"... +#4 0x0000559902f7360e in monitor_flush_locked (mon=0x559905a7f460) at ./monitor/monitor.c:160 + i = 3865830 + c = <optimized out> +#5 0x0000559902f7360e in monitor_puts (mon=mon@entry=0x559905a7f460, str=0x7f5aa1eda010 "{\"return\": \"ffff9eb480000000-ffff9eb480099000 ", '0' <repeats 11 times>, "99000 -rw\\r\\nffff9eb480099000-ffff9eb48009b000 ", '0' <repeats 12 times>, "2000 -r-\\r\\nffff9eb48009b000-ffff9eb486800000 0000000006765000 -rw\\r\\nffff9eb4868000"...) at ./monitor/monitor.c:167 + i = 3865830 + c = <optimized out> +#6 0x0000559902f74342 in qmp_send_response (mon=0x559905a7f460, rsp=<optimized out>) at ./monitor/qmp.c:119 + data = <optimized out> + json = 0x559906c88380 +#7 0x0000559902f74409 in monitor_qmp_respond (rsp=0x559905bbf740, mon=0x559905a7f460) at ./monitor/qmp.c:132 + old_mon = <optimized out> + rsp = 0x559905bbf740 + error = <optimized out> +#8 0x0000559902f74409 in monitor_qmp_dispatch (mon=0x559905a7f460, req=<optimized out>) at ./monitor/qmp.c:161 + old_mon = <optimized out> + rsp = 0x559905bbf740 + error = <optimized out> +#9 0x0000559902f74bc0 in monitor_qmp_bh_dispatcher (data=<optimized out>) at ./monitor/qmp.c:234 + id = <optimized out> + rsp = <optimized out> + need_resume = true + mon = 0x559905a7f460 + __PRETTY_FUNCTION__ = "monitor_qmp_bh_dispatcher" +#10 0x00005599030c37be in aio_bh_call (bh=0x559905571b40) at ./util/async.c:89 + bh = 0x559905571b40 + bhp = <optimized out> + next = 0x5599055718f0 + ret = 1 + deleted = false +#11 0x00005599030c37be in aio_bh_poll (ctx=ctx@entry=0x5599055706f0) at ./util/async.c:117 + bh = 0x559905571b40 + bhp = <optimized out> + next = 0x5599055718f0 + ret = 1 + deleted = false +#12 0x00005599030c6dd0 in aio_dispatch (ctx=0x5599055706f0) at ./util/aio-posix.c:459 +#13 0x00005599030c369e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ./util/async.c:260 + ctx = <optimized out> +#14 0x00007f5b6d37f417 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#15 0x00005599030c5e0a in glib_pollfds_poll () at ./util/main-loop.c:219 + context = 0x559905652420 + pfds = <optimized out> + context = 0x559905652420 + ret = 1 + mlpoll = {state = 0, timeout = 4294967295, pollfds = 0x559905651800} +#16 0x00005599030c5e0a in os_host_main_loop_wait (timeout=14451267) at ./util/main-loop.c:242 + context = 0x559905652420 + ret = 1 + mlpoll = {state = 0, timeout = 4294967295, pollfds = 0x559905651800} +#17 0x00005599030c5e0a in main_loop_wait (nonblocking=<optimized out>) at ./util/main-loop.c:518 + mlpoll = {state = 0, timeout = 4294967295, pollfds = 0x559905651800} +#18 0x0000559902dd75df in main_loop () at ./vl.c:1810 +#19 0x0000559902c59f49 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ./vl.c:4466 + i = <optimized out> + snapshot = 0 + linux_boot = <optimized out> + initrd_filename = 0x0 + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = 0x55990318bc94 "cad" + boot_once = <optimized out> + ds = <optimized out> + opts = <optimized out> + icount_opts = <optimized out> + accel_opts = 0x0 + olist = <optimized out> + optind = 100 + optarg = 0x7ffe0ca05e74 "timestamp=on" + loadvm = 0x0 + cpu_option = 0x7ffe0ca05d42 "SandyBridge-IBRS,-kvm_steal_time,+pcid,+ssbd,+spec-ctrl,+md-clear" + vga_model = 0x0 + qtest_chrdev = 0x0 + qtest_log = 0x0 + incoming = 0x0 + userconfig = <optimized out> + nographic = false + display_remote = <optimized out> + log_mask = <optimized out> + log_file = 0x0 + trace_file = <optimized out> + maxram_size = <optimized out> + ram_slots = 0 + vmstate_dump_file = 0x0 + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = false + dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffe0ca03540} + plugin_list = {tqh_first = 0x0, tqh_circ = {tql_next = 0x0, tql_prev = 0x7ffe0ca03550}} + __func__ = "main" + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1892761 b/results/classifier/118/graphic/1892761 new file mode 100644 index 000000000..171e25952 --- /dev/null +++ b/results/classifier/118/graphic/1892761 @@ -0,0 +1,49 @@ +graphic: 0.903 +device: 0.862 +performance: 0.683 +socket: 0.638 +architecture: 0.608 +network: 0.597 +arm: 0.570 +risc-v: 0.519 +vnc: 0.475 +kernel: 0.472 +user-level: 0.471 +semantic: 0.469 +i386: 0.442 +VMM: 0.403 +boot: 0.399 +PID: 0.390 +register: 0.383 +KVM: 0.368 +x86: 0.365 +debug: 0.355 +peripherals: 0.334 +assembly: 0.319 +ppc: 0.318 +TCG: 0.297 +hypervisor: 0.255 +files: 0.251 +virtual: 0.249 +mistranslation: 0.230 +permissions: 0.112 + +Heap-use-after-free through double-fetch in ehci + +Hello, +I don't have a qtest reproducer for this crash because it involves a DMA double-fetch, and I don't think we can reproduce those with qtest. + +Instead, I attached the pseudo-qtest trace produced by the fuzzer, along with some trace events. +The lines annotated with [DMA] are write commands that were triggered by a callback from a DMA read by the device. The lines annotated with [DOUBLE-FETCH] are DMA accesses that hit the same address more than once (possible double-fetches). + +I am still thinking of nicer ways of presenting this trace and providing a reproducer. +-Alex + + + +Hi Alexander! Have you ever been able to create a reproducer for this problem? + +No. If we figure out some way to consistently reproduce double-fetches in a non-fuzzer build, I'll report the issue again, but this can probably be closed + +Ok, let's close this one since it was not reproducible. If you find a reproducer, please open a new ticket in the gitlab tracker instead. + diff --git a/results/classifier/118/graphic/1893 b/results/classifier/118/graphic/1893 new file mode 100644 index 000000000..af76f6b18 --- /dev/null +++ b/results/classifier/118/graphic/1893 @@ -0,0 +1,43 @@ +graphic: 0.919 +device: 0.864 +virtual: 0.827 +PID: 0.714 +mistranslation: 0.650 +network: 0.643 +socket: 0.620 +vnc: 0.613 +kernel: 0.568 +arm: 0.565 +semantic: 0.559 +boot: 0.545 +KVM: 0.541 +ppc: 0.528 +VMM: 0.510 +hypervisor: 0.471 +i386: 0.457 +risc-v: 0.421 +performance: 0.389 +TCG: 0.353 +architecture: 0.353 +debug: 0.349 +user-level: 0.334 +register: 0.305 +peripherals: 0.274 +x86: 0.267 +files: 0.266 +permissions: 0.158 +assembly: 0.046 + +assert on savevm +Description of problem: + +Steps to reproduce: +1. launch as above (n.b. qemu-img command: qemu-img create -f qcow2 rootfs.qcow2 60G +2. from qemu monitor: savevm test +3. On stderr + +``` +Assertion failed: (qemu_get_current_aio_context() == qemu_get_aio_context()), function bdrv_poll_co, file block-gen.h, line 43. +``` +Additional information: + diff --git a/results/classifier/118/graphic/1894 b/results/classifier/118/graphic/1894 new file mode 100644 index 000000000..a78de360a --- /dev/null +++ b/results/classifier/118/graphic/1894 @@ -0,0 +1,41 @@ +graphic: 0.850 +device: 0.783 +files: 0.536 +mistranslation: 0.474 +virtual: 0.441 +arm: 0.327 +semantic: 0.325 +risc-v: 0.305 +socket: 0.303 +register: 0.249 +architecture: 0.238 +ppc: 0.230 +boot: 0.226 +debug: 0.201 +performance: 0.177 +user-level: 0.156 +i386: 0.155 +permissions: 0.147 +PID: 0.133 +vnc: 0.127 +TCG: 0.117 +kernel: 0.113 +x86: 0.071 +peripherals: 0.066 +VMM: 0.059 +assembly: 0.056 +hypervisor: 0.055 +network: 0.054 +KVM: 0.007 + +Can't emulate audio with OpenCore Mac OS X 10.7 +Description of problem: +OpenCore wants me to use `AppleALC`, but to use _that_, I need the layout ID of the motherboard or something and I'm not sure how I'd do that since it's a QEMU VM. All I want to do is have some audio :( + +So, how can I emulate audio with AppleALC + OpenCore/how can I get a layout ID that'll give me audio on a QEMU VM? Do note that I am using UTM (https://getutm.app/) (UTM uses QEMU and is basically a QEMU frontend). +Steps to reproduce: +1. Set up OpenCore and install Mac OS X 10.7 +2. Copy across a .mp3 file +3. iTunes fails to play it due to no audio drivers/audio outputs +Additional information: +N/A diff --git a/results/classifier/118/graphic/1894617 b/results/classifier/118/graphic/1894617 new file mode 100644 index 000000000..077d9bac7 --- /dev/null +++ b/results/classifier/118/graphic/1894617 @@ -0,0 +1,86 @@ +graphic: 0.926 +device: 0.910 +permissions: 0.903 +register: 0.891 +assembly: 0.885 +peripherals: 0.875 +semantic: 0.875 +i386: 0.866 +debug: 0.865 +architecture: 0.861 +socket: 0.859 +hypervisor: 0.856 +arm: 0.855 +user-level: 0.850 +PID: 0.828 +mistranslation: 0.823 +VMM: 0.821 +virtual: 0.818 +ppc: 0.807 +vnc: 0.806 +TCG: 0.787 +risc-v: 0.784 +network: 0.774 +files: 0.762 +performance: 0.755 +kernel: 0.745 +x86: 0.740 +KVM: 0.702 +boot: 0.557 + +qemu-i386 mmap but offset greater than 32 bits + +I don't know if it's a problem, but I did, and it bothered me for a long time. +When I use qemu-i386 and interact with the video card device,an error has occurred: + +18534 ioctl(4,DRM_IOCTL_MODE_GETENCODER,{39,0,0,0,0}) = 0 ({39,4,34,3,0}) +18534 ioctl(4,DRM_IOCTL_MODE_CREATE_DUMB,{1080,1920,32,0,0,0,0}) = 0 ({1080,1920,32,0,1,7680,8294400}) +18534 ioctl(4,DRM_IOCTL_MODE_ADDFB,{0,1920,1080,7680,32,24,1}) = 0 ({66,1920,1080,7680,32,24,1}) +18534 ioctl(4,DRM_IOCTL_MODE_MAP_DUMB,{1,0,0}) = 0 ({1,0,5543018496}) +18534 mmap2(NULL,8294400,PROT_READ|PROT_WRITE,MAP_SHARED,4,0x14a63c) = -1 errno=22 (Invalid argument) + +"5543018496" is the offset through ioctl() and it is "0x14a63c000". +In qemu： +ret = target_mmap(arg1, arg2, arg3, + target_to_host_bitmask(arg4, mmap_flags_tbl), + arg5, arg6 << MMAP_SHIFT); + +The type of "arg6" is ulong.When use qemu-i386, arg6 can't be set to "0x14a63c000".So it's wrong for my program. + +I want to find a good way to deal with this kind of problem, but I'm not very familiar with QEMU， +so I came to ask how to deal with this problem. + +Thank you！ + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1895602 b/results/classifier/118/graphic/1895602 new file mode 100644 index 000000000..d883b4dc3 --- /dev/null +++ b/results/classifier/118/graphic/1895602 @@ -0,0 +1,74 @@ +graphic: 0.892 +user-level: 0.826 +device: 0.799 +boot: 0.790 +performance: 0.751 +files: 0.727 +permissions: 0.702 +architecture: 0.701 +hypervisor: 0.688 +PID: 0.688 +register: 0.656 +kernel: 0.650 +network: 0.648 +i386: 0.643 +x86: 0.634 +mistranslation: 0.632 +debug: 0.625 +semantic: 0.621 +risc-v: 0.618 +vnc: 0.616 +TCG: 0.599 +socket: 0.591 +peripherals: 0.579 +ppc: 0.566 +VMM: 0.561 +virtual: 0.561 +arm: 0.554 +assembly: 0.551 +KVM: 0.507 + +older OS's do not detect CD change + +There are at least two older operating systems, being FreeBSD 2.2 and FreeDOS 1.2, that misbehave when the change command is used on the IDE CD drive, and work fine on a real machine. In both cases, changing the CD causes the guest to either refuse to read the disc or appear to read bad data, and in both cases the guest read the disc without issue after a system_reset. + +A HD image that demonstrates this behavior can be produced if necessary, however the FreeDOS 1.2 CD can be booted directly and used to test: + +http://freedos.org/download/download/FD12CD.iso + +(choose install then abort and you get a prompt in which you can type "dir D:", say) + +note, running eject before the change command does nothing to help. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1896342 b/results/classifier/118/graphic/1896342 new file mode 100644 index 000000000..bed5551dd --- /dev/null +++ b/results/classifier/118/graphic/1896342 @@ -0,0 +1,113 @@ +graphic: 0.874 +peripherals: 0.832 +semantic: 0.811 +assembly: 0.799 +user-level: 0.774 +permissions: 0.766 +network: 0.758 +performance: 0.753 +architecture: 0.746 +virtual: 0.743 +debug: 0.738 +socket: 0.736 +device: 0.732 +register: 0.728 +PID: 0.726 +files: 0.715 +risc-v: 0.690 +hypervisor: 0.682 +kernel: 0.670 +TCG: 0.663 +arm: 0.643 +VMM: 0.643 +mistranslation: 0.641 +ppc: 0.606 +x86: 0.590 +vnc: 0.587 +KVM: 0.571 +boot: 0.565 +i386: 0.490 + +IDE ATA IDENTIFY WORD 106 + +The code at line 202 in hw/ide/core.c + (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ide/core.c;#l201) +hard codes bit 13 set. However, get_physical_block_exp() can and may return 0, which is a valid response. If get_physical_block_exp() does return zero, bit 13 should not be set. + +ATAPI8 states (Section 7.17.7.73): + "Bit 13 of word 106 shall be set to one to indicate that the device has more than one logical sector per physical sector" + +and gives the examples: + Bits (3:0): 0 = 2^0 = 1 logical sector per physical sector + Bits (3:0): 1 = 2^1 = 2 logical sector per physical sector + Bits (3:0): 2 = 2^2 = 4 logical sector per physical sector + Bits (3:0): 3 = 2^3 = 8 logical sector per physical sector + +Therefore, if bit 13 is set, bits 3:0 must be greater than zero. + +If get_physical_block_exp() returns zero then there is a 1:1 ratio and bit 13 must be 0. + +Just my opinion. + +Thanks, +Ben + +For more information, Annex-E of the ACS-2 explains this as well. + +http://www.t13.org/Documents/UploadedDocuments/docs2009/d2015r2-ATAATAPI_Command_set_-_2_ACS-2.pdf + +See the statement on the top of page 165 as well. "If bit 13 is set, then bits 3:0 are valid". + +Page 119 of that same document states: + "13 1 = Device has multiple logical sectors per physical sector." + +In my opinion, if bit 13 is set and bits 3:0 are valid, then bits 3:0 should be non-zero. + +Therefore, I gather that in QEMU (assuming that get_physical_block_exp() returns the same value shown in the example listing above): + +1) if get_physical_block_exp() return a non-zero value, bit 13 must be set and bits 3:0 will be non-zero. +2) if get_physical_block_exp() return a zero value, bit 13 must be clear and bits 3:0 must be ignored. + +Please correct me if I am wrong in these assumptions. + +Thanks, +Ben + +You might be right, though at present it seems like it doesn't hurt anything that I am aware of to claim that our mapping is 1:1 in such cases. + +Patches welcome; especially if there is any proof that this has caused any problems anywhere. + +--js + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1901 b/results/classifier/118/graphic/1901 new file mode 100644 index 000000000..51c6b91d4 --- /dev/null +++ b/results/classifier/118/graphic/1901 @@ -0,0 +1,49 @@ +graphic: 0.871 +architecture: 0.853 +performance: 0.843 +device: 0.723 +semantic: 0.696 +permissions: 0.608 +PID: 0.536 +ppc: 0.492 +virtual: 0.457 +network: 0.432 +files: 0.432 +peripherals: 0.422 +socket: 0.404 +vnc: 0.392 +register: 0.377 +hypervisor: 0.373 +TCG: 0.314 +debug: 0.287 +VMM: 0.269 +kernel: 0.267 +arm: 0.256 +risc-v: 0.245 +mistranslation: 0.243 +user-level: 0.241 +boot: 0.231 +assembly: 0.079 +KVM: 0.079 +x86: 0.068 +i386: 0.060 + +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/118/graphic/1905226 b/results/classifier/118/graphic/1905226 new file mode 100644 index 000000000..05ee0cb09 --- /dev/null +++ b/results/classifier/118/graphic/1905226 @@ -0,0 +1,78 @@ +graphic: 0.878 +device: 0.820 +performance: 0.771 +semantic: 0.767 +kernel: 0.743 +network: 0.723 +architecture: 0.711 +register: 0.708 +mistranslation: 0.676 +socket: 0.672 +vnc: 0.667 +user-level: 0.666 +peripherals: 0.654 +PID: 0.647 +permissions: 0.633 +files: 0.619 +risc-v: 0.556 +hypervisor: 0.553 +debug: 0.552 +ppc: 0.543 +arm: 0.525 +VMM: 0.494 +boot: 0.491 +TCG: 0.482 +assembly: 0.460 +x86: 0.451 +KVM: 0.432 +i386: 0.411 +virtual: 0.258 + +intel-hda: stream reset bits are broken + +From HD audio spec, section 3.3.35: + +"Stream Reset (SRST): Writing a 1 causes the corresponding stream to be reset. [...] After the stream hardware has completed sequencing into the reset state, it will report a 1 in this bit. Software must read a 1 from this bit to verify that the stream is in reset. Writing a 0 causes the corresponding stream to exit reset. When the stream hardware is ready to begin operation, it will report a 0 in this bit. Software must read a 0 from this bit before accessing any of the stream registers." + +So to reset a stream I set the bit, but it never reads back as 1 so the driver either times out or will hang forever waiting for it to become 1. I looked into why this happens and found that as of the latest version (8110fa1), in function intel_hda_set_st_ctl() of the https://github.com/qemu/qemu/blob/master/hw/audio/intel-hda.c, + + if (st->ctl & 0x01) { + /* reset */ + dprint(d, 1, "st #%d: reset\n", reg->stream); + st->ctl = SD_STS_FIFO_READY << 24; + } + +This causes the bit to immediately become set to 0 even if I write a 1, and clearly does not meet the spec. I checked behaviour of real hardware and it works as expected, i.e. I see the bit will become 1 and 0 when I write to it. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1906184 b/results/classifier/118/graphic/1906184 new file mode 100644 index 000000000..e0905753e --- /dev/null +++ b/results/classifier/118/graphic/1906184 @@ -0,0 +1,91 @@ +graphic: 0.897 +peripherals: 0.874 +socket: 0.853 +KVM: 0.851 +network: 0.831 +device: 0.821 +architecture: 0.819 +arm: 0.804 +user-level: 0.804 +risc-v: 0.798 +PID: 0.793 +boot: 0.774 +mistranslation: 0.765 +vnc: 0.759 +hypervisor: 0.759 +ppc: 0.758 +performance: 0.747 +permissions: 0.740 +x86: 0.727 +virtual: 0.715 +files: 0.713 +kernel: 0.710 +VMM: 0.701 +semantic: 0.700 +register: 0.689 +debug: 0.689 +TCG: 0.677 +assembly: 0.607 +i386: 0.602 + +Lots of stuttering/crackling in guest sound + +When listening to music (e.g. with VLC) or watching Youtube on the guest, there's lots of stuttering and crackling in the sound. + + +Tested with the following QEMU start commands: + +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga virtio -soundhw hda -display sdl,gl=on + +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display sdl + +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display gtk + + +If I use the following command (QXL graphics, "remote" access via SPICE over unix socket), stuttering is not completely gone but MUCH less annoying: + +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -soundhw hda -vga qxl -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent -spice unix,addr=/tmp/vm_spice.socket,disable-ticketing + +and this command for accessing the VM: +remote-viewer spice+unix:///tmp/vm_spice.socket + + + +Guest: Kubuntu 20.04 64-bit (live), but occurs with many other as well +Host: Arch Linux, with KDE desktop +CPU: Intel Xeon E3-1230v2 (4 cores + hyperthreading) +RAM: 16 GB +GPU: Nvidia GTX 980 Ti + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1906185 b/results/classifier/118/graphic/1906185 new file mode 100644 index 000000000..50e994604 --- /dev/null +++ b/results/classifier/118/graphic/1906185 @@ -0,0 +1,94 @@ +graphic: 0.980 +socket: 0.958 +user-level: 0.952 +virtual: 0.948 +device: 0.938 +risc-v: 0.935 +boot: 0.915 +files: 0.898 +arm: 0.890 +architecture: 0.884 +network: 0.882 +peripherals: 0.875 +permissions: 0.873 +mistranslation: 0.865 +register: 0.859 +PID: 0.856 +semantic: 0.827 +kernel: 0.817 +performance: 0.815 +hypervisor: 0.814 +x86: 0.791 +vnc: 0.714 +ppc: 0.708 +debug: 0.650 +assembly: 0.639 +TCG: 0.608 +KVM: 0.591 +VMM: 0.573 +i386: 0.457 + +Guest display resolution cannot be changed when using certain graphics/interface combinations + +Guest display resolution cannot be changed with certain virtual graphics card (-vga) and interface (-display) combinations. + +For example, resolution changing doesn't work with the following QEMU start commands, it resets to the default resolution immediately: + +QXL with SDL interface: +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display sdl + +QXL with GTK interface: +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display gtk + +QXL with "remote" SPICE interface via unix socket: +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -soundhw hda -vga qxl -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent -spice unix,addr=/tmp/vm_spice.socket,disable-ticketing + +for "remote" access: +remote-viewer spice+unix:///tmp/vm_spice.socket + + + +Other tested combinations: +-- virtio + SDL (GL on): works! +-- virtio + GTK (GL on): does not work properly. The resolution is changed but window size is not so the guest screen will look like garbage. +-- vmware: The initial Kubuntu setup screen is visible but booting does not progress to the desktop +-- std + GTK: works! +-- std + SDL: works! + + +QEMU version: 5.1.0 +Guest: Kubuntu 20.04 64-bit (live) with 5.4.0-26 kernel; may occur with other guests as well +Host: Arch Linux, with KDE desktop + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1907137 b/results/classifier/118/graphic/1907137 new file mode 100644 index 000000000..08abea4fa --- /dev/null +++ b/results/classifier/118/graphic/1907137 @@ -0,0 +1,178 @@ +graphic: 0.884 +register: 0.869 +debug: 0.862 +user-level: 0.843 +permissions: 0.843 +peripherals: 0.835 +virtual: 0.834 +risc-v: 0.811 +semantic: 0.802 +performance: 0.798 +mistranslation: 0.798 +PID: 0.790 +socket: 0.786 +device: 0.781 +assembly: 0.778 +TCG: 0.762 +architecture: 0.762 +ppc: 0.752 +vnc: 0.751 +arm: 0.744 +hypervisor: 0.741 +kernel: 0.725 +VMM: 0.718 +KVM: 0.712 +network: 0.709 +boot: 0.669 +files: 0.669 +x86: 0.649 +i386: 0.539 + +LDTR not properly emulated when MTE tag checks enabled at EL0 + +I am trying to boot Android (just the non-GUI parts for now) under QEMU with MTE enabled. This can be done by following the instructions here to build the fvp-eng target with MTE support: + +https://cs.android.com/android/platform/superproject/+/master:device/generic/goldfish/fvpbase/ + +and launching QEMU with the following command: + +qemu-system-aarch64 -kernel $ANDROID_PRODUCT_OUT/kernel -initrd $ANDROID_PRODUCT_OUT/combined-ramdisk.img -machine virt,mte=on -cpu max -drive driver=raw,file=$ANDROID_PRODUCT_OUT/system-qemu.img,if=none,id=system -device virtio-blk-device,drive=system -append "console=ttyAMA0 earlyprintk=ttyAMA0 androidboot.hardware=fvpbase androidboot.boot_devices=a003e00.virtio_mmio loglevel=9 printk.devkmsg=on buildvariant=eng" -m 512 -nographic -no-reboot + +If I do this then QEMU crashes like so: + +** +ERROR:../target/arm/mte_helper.c:558:mte_check_fail: code should not be reached +Bail out! ERROR:../target/arm/mte_helper.c:558:mte_check_fail: code should not be reached + +The error is caused by an MTE tag check fault from an LDTR instruction in __arch_copy_from_user. At this point TCF=0 and TCF0=2. + +I have this patch that gets me past the error but it is unclear whether this is the correct fix since there may be other confusion between TCF and TCF0 elsewhere. + +diff --git a/target/arm/mte_helper.c b/target/arm/mte_helper.c +index 153bd1e9df..aa5db4eac4 100644 +--- a/target/arm/mte_helper.c ++++ b/target/arm/mte_helper.c +@@ -552,10 +552,8 @@ static void mte_check_fail(CPUARMState *env, uint32_t desc, + case 0: + /* + * Tag check fail does not affect the PE. +- * We eliminate this case by not setting MTE_ACTIVE +- * in tb_flags, so that we never make this runtime call. + */ +- g_assert_not_reached(); ++ break; + + case 2: + /* Tag check fail causes asynchronous flag set. */ + +The workaround patch above is insufficient if I change userspace to set TCF0=1. With that I get a kernel panic: + +[ 13.336255][ C0] Bad mode in Synchronous Abort handler detected on CPU0, code 0x92000011 -- DABT (lower EL) +[ 13.337437][ C0] CPU: 0 PID: 1 Comm: init Not tainted 5.10.0-rc7-mainline-00300-gf4328758abb6 #1 +[ 13.338086][ C0] Hardware name: linux,dummy-virt (DT) +[ 13.338948][ C0] pstate: 20400005 (nzCv daif +PAN -UAO -TCO BTYPE=--) +[ 13.339951][ C0] pc : __arch_copy_from_user+0x1e4/0x340 +[ 13.340483][ C0] lr : _copy_from_user+0xbc/0x564 +[ 13.340930][ C0] sp : ffffffc01000bda0 +[ 13.341385][ C0] x29: ffffffc01000bda0 +[ 13.342295][ C0] x28: ffffff804011c100 +[ 13.342951][ C0] +[ 13.343321][ C0] x27: 0000000000000000 +[ 13.343759][ C0] x26: 0000000000000000 +[ 13.344178][ C0] +[ 13.344513][ C0] x25: 0000000000000000 +[ 13.344954][ C0] x24: 0000000000000000 +[ 13.345382][ C0] +[ 13.345713][ C0] x23: 0300007e18aca850 +[ 13.346153][ C0] x22: 0300007e18aca860 +[ 13.346809][ C0] +[ 13.347144][ C0] x21: ffffff8043d1ef80 +[ 13.347596][ C0] x20: 0300007e18aca850 +[ 13.348023][ C0] +[ 13.348354][ C0] x19: ffffff8043295000 +[ 13.348806][ C0] x18: ffffff8040103c38 +[ 13.349232][ C0] +[ 13.349557][ C0] x17: 0000000004000000 +[ 13.349998][ C0] x16: 0000007fffffffff +[ 13.350634][ C0] +[ 13.350965][ C0] x15: 0000007f9fed34f8 +[ 13.351409][ C0] x14: 006d65747379730c +[ 13.351844][ C0] +[ 13.352167][ C0] x13: 00000000000001ed +[ 13.352610][ C0] x12: 0000000000000000 +[ 13.353034][ C0] +[ 13.353358][ C0] x11: 0000000000000000 +[ 13.353802][ C0] x10: 0000000000000000 +[ 13.354232][ C0] +[ 13.354785][ C0] x9 : 006d65747379730c +[ 13.355236][ C0] x8 : 0000000000000000 +[ 13.355673][ C0] +[ 13.355998][ C0] x7 : 0000000000000000 +[ 13.356448][ C0] x6 : ffffff8043295040 +[ 13.356874][ C0] +[ 13.357200][ C0] x5 : ffffff8043296000 +[ 13.357646][ C0] x4 : 0000000000000000 +[ 13.358077][ C0] +[ 13.358423][ C0] x3 : 0000000000000001 +[ 13.359055][ C0] x2 : 0000000000000f80 +[ 13.359497][ C0] +[ 13.359829][ C0] x1 : 0300007e18aca8c0 +[ 13.360278][ C0] x0 : ffffff8043295000 +[ 13.360705][ C0] +[ 13.362315][ C0] Kernel panic - not syncing: bad mode +[ 13.362377][ C0] CPU: 0 PID: 1 Comm: init Not tainted 5.10.0-rc7-mainline-00300-gf4328758abb6 #1 +[ 13.362410][ C0] Hardware name: linux,dummy-virt (DT) +[ 13.362442][ C0] Call trace: +[ 13.362474][ C0] dump_backtrace+0x0/0x1e0 +[ 13.362507][ C0] show_stack+0x1c/0x2c +[ 13.362539][ C0] dump_stack+0xd0/0x154 +[ 13.362570][ C0] panic+0x158/0x370 +[ 13.362602][ C0] bad_el0_sync+0x0/0x5c +[ 13.362634][ C0] el1_inv+0x3c/0x5c +[ 13.362666][ C0] el1_sync_handler+0x64/0x8c +[ 13.362698][ C0] el1_sync+0x84/0x140 +[ 13.362730][ C0] __arch_copy_from_user+0x1e4/0x340 +[ 13.362762][ C0] copy_mount_options+0x40/0x1d0 +[ 13.362794][ C0] __arm64_sys_mount+0x84/0x13c +[ 13.362826][ C0] el0_svc_common+0xc0/0x1b4 +[ 13.362858][ C0] do_el0_svc+0x20/0x30 +[ 13.362890][ C0] el0_svc+0x14/0x24 +[ 13.362922][ C0] el0_sync_handler+0x88/0xec +[ 13.362953][ C0] el0_sync+0x17c/0x180 +[ 13.363547][ C0] Kernel Offset: 0x2abd800000 from 0xffffffc010000000 +[ 13.363580][ C0] PHYS_OFFSET: 0x40000000 +[ 13.363613][ C0] CPU features: 0x27e0152,6180a230 +[ 13.363644][ C0] Memory Limit: none + +It looks like the tag check fault coming from the LDTR is reported using the wrong EL. + +From the hash id in your patch, it would appear that you are using a fork of qemu. + +This should be fixed by 50244cc76abc present in the qemu 5.2 release. + +This isn't a fork of qemu, it was an upstream checkout based on commit 944fdc5e27a5b5adbb765891e8e70e88ba9a00ec (well, okay, I did have the ARM HVF series applied to this checkout, but I wouldn't expect that to affect TCG). I verified that 50244cc76abc is present in my checkout. + +Let me see if I can reproduce with the current upstream master. + +Ok, I'll have a deeper look as well. + +rebuild_hflags_a64 is not consistent with mte_check_fail, +which leads to the assert reported. + +The instructions for building the android kernel are opaque, +assuming tools not in evidence. + +Thanks, I will try that patch. + +Apologies, the instructions assume some familiarity with building Android. You will find instructions for downloading the "repo" tool and the Android source tree here: + +https://source.android.com/setup/build/downloading + +This isn't the first time I've received this kind of feedback. I will add a link to that page to the document. + +Thanks for the patch. I've verified that it fixes the assertion failure with both TCF0=1 and TCF0=2. + +You can disregard the kernel panic from comment #1 since it turns out that it was from an older build of QEMU that did not have 50244cc76abc. + +https://gitlab.com/qemu-project/qemu/-/commit/cc97b0019bb590b9b3c + diff --git a/results/classifier/118/graphic/1908266 b/results/classifier/118/graphic/1908266 new file mode 100644 index 000000000..9c94c1fa5 --- /dev/null +++ b/results/classifier/118/graphic/1908266 @@ -0,0 +1,70 @@ +graphic: 0.804 +mistranslation: 0.785 +semantic: 0.781 +device: 0.679 +peripherals: 0.546 +performance: 0.430 +vnc: 0.391 +architecture: 0.381 +hypervisor: 0.366 +network: 0.349 +user-level: 0.339 +permissions: 0.334 +virtual: 0.326 +ppc: 0.306 +register: 0.228 +PID: 0.222 +files: 0.216 +risc-v: 0.201 +socket: 0.194 +i386: 0.193 +x86: 0.193 +assembly: 0.189 +arm: 0.185 +debug: 0.179 +TCG: 0.176 +VMM: 0.160 +KVM: 0.144 +kernel: 0.139 +boot: 0.136 + +spice unnecessary forces nographic + +When spice is enabled, qemu does not give the graphical window. It should not imply -nographic but only -display none. + +More precisely, there should be a way to prevent -vga qxl from being wired to the graphical window. + +Not clear what you are looking for ... + +-spice doesn't imply -nographic. +-spice flips the default for -display to none. +-vnc has the same effect btw. + +You can use -display {gtk,sdl} and -spice at the same time, +but you have to explicitly enable -display then. + + +The gtk window is not limited for -display but also for compatmonitor / serial /paralel, but when -spice is used, the gtk window does not show at all. While you can force the window to show with -display gtk, but the *side effect* is the vga will be wired/connected to the gtk window (which seems to break things when gl and so on is enabled). + +Yes, display devices show up on both UI and spice/vnc, +and right now there is no way to contigure that. + +Using spice fot the vga and gtk for serial/monitor +is rather unusual though. Any reason for this? + +I'd suggest to simply use the gtk ui instead. +It works with opengl (-display gtk,gl=on). +You also can show stuff side-by-side in +separate windows, via menu -> view -> detach tab. + + + +Does the spice protocol / any spice client allow access to compatmonitor / serial /paralel? + +Spice can be (if not often / mainly) used for remote access like VNC, but that does not necessarily mean users would want to host "fully-headless". + +Try "qemu -display spice-app", then go to menu -> view -> displays in virt-viewer. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1912846 b/results/classifier/118/graphic/1912846 new file mode 100644 index 000000000..6a8eda4ed --- /dev/null +++ b/results/classifier/118/graphic/1912846 @@ -0,0 +1,51 @@ +x86: 0.995 +graphic: 0.967 +device: 0.953 +network: 0.937 +socket: 0.912 +i386: 0.901 +ppc: 0.901 +peripherals: 0.879 +vnc: 0.869 +performance: 0.855 +architecture: 0.823 +PID: 0.811 +files: 0.773 +arm: 0.760 +kernel: 0.742 +risc-v: 0.736 +permissions: 0.718 +semantic: 0.700 +debug: 0.657 +VMM: 0.617 +TCG: 0.603 +register: 0.602 +boot: 0.564 +user-level: 0.551 +mistranslation: 0.541 +hypervisor: 0.487 +virtual: 0.470 +assembly: 0.364 +KVM: 0.342 + +Assertion hit on hot-unplugging virtio iommu enabled device + +From commit ("2d24a646 device-core: use RCU for +list of children of a bus") an assertion is hit when +removing a device, since mr->listeners are not properly +removed. To reproduce: + +/home/qemu/build/x86_64-softmmu/qemu-system-x86_64 -qmp tcp:0:4444,server,nowait ... \ + -netdev tap,id=hostnet0,vhostforce=on,vhost=on \ + -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:14:18:cc,bus=pci.1,addr=0x0,iommu_platform=on,ats=on + +In QMP: +{'execute': 'qmp_capabilities'} +{"execute": "device_del", "arguments": {"id": "net0"} } + +And crash: +../softmmu/memory.c:2818: do_address_space_destroy: Assertion `QTAILQ_EMPTY(&as->listeners)' failed. + +Fixed here: +https://gitlab.com/qemu-project/qemu/-/commit/f6ab64c05f8a6229bf6 + diff --git a/results/classifier/118/graphic/1913 b/results/classifier/118/graphic/1913 new file mode 100644 index 000000000..1aa6941c7 --- /dev/null +++ b/results/classifier/118/graphic/1913 @@ -0,0 +1,49 @@ +graphic: 0.943 +performance: 0.896 +device: 0.876 +user-level: 0.839 +arm: 0.824 +debug: 0.730 +architecture: 0.691 +socket: 0.677 +register: 0.664 +network: 0.603 +mistranslation: 0.595 +semantic: 0.578 +PID: 0.558 +boot: 0.538 +kernel: 0.531 +permissions: 0.526 +files: 0.520 +vnc: 0.493 +risc-v: 0.452 +peripherals: 0.446 +ppc: 0.419 +VMM: 0.351 +virtual: 0.328 +x86: 0.297 +TCG: 0.293 +hypervisor: 0.287 +assembly: 0.261 +i386: 0.217 +KVM: 0.198 + +Regression in 8.1.1: qemu-aarch64-static running ldconfig +Description of problem: +Since updating to 8.1.1, qemu crashes when running ldconfig in my sysroot (It's a more or less default Ubuntu 22.04 arm64 rootfs) +Steps to reproduce: +1. Download the arm64 ubuntu base from https://cdimage.ubuntu.com/ubuntu-base/releases/jammy/release/ +2. Extract it +3. Run `qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs` where `rootfs` is where you extracted it with qemu 8.1.1 + +```bash +$ qemu-aarch64-static --version +qemu-aarch64 version 8.1.0 +$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs +<works> +$ sudo pacman -U /var/cache/pacman/pkg/qemu-user-static*-8.1.1*.zst +$ qemu-aarch64-static --version +qemu-aarch64 version 8.1.1 +$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs +<segfault> +``` diff --git a/results/classifier/118/graphic/1915 b/results/classifier/118/graphic/1915 new file mode 100644 index 000000000..5ef97b686 --- /dev/null +++ b/results/classifier/118/graphic/1915 @@ -0,0 +1,41 @@ +graphic: 0.897 +device: 0.744 +semantic: 0.370 +ppc: 0.324 +boot: 0.323 +mistranslation: 0.290 +PID: 0.251 +permissions: 0.213 +i386: 0.192 +vnc: 0.187 +files: 0.187 +register: 0.170 +debug: 0.169 +x86: 0.157 +network: 0.143 +user-level: 0.134 +hypervisor: 0.131 +socket: 0.130 +risc-v: 0.121 +performance: 0.110 +architecture: 0.104 +arm: 0.104 +VMM: 0.088 +virtual: 0.084 +TCG: 0.047 +assembly: 0.047 +kernel: 0.033 +peripherals: 0.029 +KVM: 0.021 + +whpx causes a blue screen on guest windows +Description of problem: +i wanted to install windows 7 with qemu, but qunad i tried i got a blue screen . Then I downgraded to version 5.0.2 and it worked perfectly, I also tried with windows 10 and it didn't boot. + + +Steps to reproduce: +1. install windows 7 iso +2. run the setup +3. and the bsod.. +Additional information: +I tried it with qemu 5.0.2 and it worked perfectly. diff --git a/results/classifier/118/graphic/1916343 b/results/classifier/118/graphic/1916343 new file mode 100644 index 000000000..2a4a0d66d --- /dev/null +++ b/results/classifier/118/graphic/1916343 @@ -0,0 +1,92 @@ +graphic: 0.922 +semantic: 0.918 +user-level: 0.882 +permissions: 0.879 +mistranslation: 0.871 +register: 0.871 +performance: 0.860 +risc-v: 0.848 +device: 0.847 +virtual: 0.835 +VMM: 0.834 +architecture: 0.828 +vnc: 0.822 +PID: 0.821 +peripherals: 0.820 +assembly: 0.817 +ppc: 0.814 +debug: 0.803 +arm: 0.798 +TCG: 0.790 +socket: 0.782 +hypervisor: 0.772 +files: 0.750 +x86: 0.725 +network: 0.725 +kernel: 0.721 +boot: 0.693 +KVM: 0.663 +i386: 0.479 + +-daemonize not working on macOS + +Basically e.g, if I try with below command on macOS: + +qemu-system-x86_64 \ + -m 4G \ + -vga virtio \ + -display default,show-cursor=on \ + -usb \ + -device usb-tablet \ + -machine type=q35,accel=hvf \ + -smp 2 \ + -drive file=ubuntu.qcow2,if=virtio -cpu max \ + -net nic -net user,hostfwd=tcp::50022-:22,hostfwd=tcp::8000-:80 \ + -daemonize + +With this command, the QEMU processes hang there forever. I guess there is a bug when forking a child and kill the parent? Because when this issue occurs, there are actually 2 QEMU processes running + +``` + 501 14952 14951 0 7:08PM ?? 0:00.00 (qemu-system-x86_) + 501 14953 1 0 7:08PM ?? 0:00.03 qemu-system-x86_64 -m 4G -vga virtio -display default,show-cursor=on -usb -device usb-tablet -machine type=q35,accel=hvf -smp 2 -drive file=ubuntu.qcow2,if=virtio -cpu max -net nic -net user,hostfwd=tcp::50022-:22,hostfwd=tcp::8000-:80 -daemonize + 501 14951 14626 0 7:08PM ttys000 0:00.03 qemu-system-x86_64 -m 4G -vga virtio -display default,show-cursor=on -usb -device usb-tablet -machine type=q35,accel=hvf -smp 2 -drive file=ubuntu.qcow2,if=virtio -cpu max -net nic -net user,hostfwd=tcp::50022-:22,hostfwd=tcp::8000-:80 -daemonize +``` + +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/313 + + diff --git a/results/classifier/118/graphic/1917394 b/results/classifier/118/graphic/1917394 new file mode 100644 index 000000000..c7bb626e2 --- /dev/null +++ b/results/classifier/118/graphic/1917394 @@ -0,0 +1,420 @@ +graphic: 0.947 +virtual: 0.944 +semantic: 0.940 +register: 0.935 +permissions: 0.929 +debug: 0.915 +assembly: 0.910 +device: 0.907 +peripherals: 0.898 +architecture: 0.895 +user-level: 0.891 +risc-v: 0.884 +performance: 0.883 +PID: 0.874 +boot: 0.872 +arm: 0.857 +VMM: 0.849 +ppc: 0.847 +vnc: 0.846 +files: 0.838 +hypervisor: 0.835 +kernel: 0.832 +network: 0.827 +mistranslation: 0.825 +KVM: 0.813 +socket: 0.811 +TCG: 0.786 +x86: 0.770 +i386: 0.651 + +command lspci does not show the IVSHMEM device + +qeum version: +QEMU emulator version 4.2.1 + +I met a problem when I tried to use IVSHMEM. Command lspci does not show the IVSHMEM device. +Below is the configuration from my side: + +1. guest vm xml configuration. + <shmem name='ivshmem'> + <model type='ivshmem-plain'/> + <size unit='M'>2</size> + <address type='pci' domain='0x0000' bus='0x00' slot='0x10' function='0x0'/> + </shmem> + +2. after the booting up and I found the qemu commandline ideedly have the device option: +ps aux | grep ivshmem + /usr/bin/qemu-system-x86_64 + .......(ignore other options) +-object memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 + +3. lspci command not shown the device. + +4. lshw command indeedly show the device: + +*-memory UNCLAIMED + description: RAM memory + product: Inter-VM shared memory + vendor: Red Hat, Inc. + physical id: 10 + bus info: pci@0000:00:10.0 + version: 01 + width: 64 bits + clock: 33MHz (30.3ns) + configuration: latency=0 + resources: memory:fcc1c000-fcc1c0ff memory:fdc00000-fdffffff + +My host and vm os is ubuntu 20.04 and version is: +#49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux + +Hi ChangLimin, + +Thanks for your reply. I checked again to find the device... I thought the +name was ivshmem. +I don't find any driver code for IVSHMEM in the linux and qemu repo. Can +you give me some help? + +00:10.0 RAM memory: Red Hat, Inc. Inter-VM shared memory (rev 01) +Subsystem: Red Hat, Inc. QEMU Virtual Machine +Flags: fast devsel +Memory at fcc1c000 (32-bit, non-prefetchable) [size=256] +Memory at fdc00000 (64-bit, prefetchable) [size=4M] + +Thanks, +Sean + + + + + + +On Tue, Mar 2, 2021 at 3:31 PM ChangLimin <email address hidden> wrote: + +> Can you give the lspci messages? The below is my output. There is a RAM +> memory device. +> +> $ lspci +> 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev +> 02) +> 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] +> 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton +> II] +> 00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton +> II] (rev 01) +> 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) +> 00:02.0 VGA compatible controller: Device 1234:1111 (rev 02) +> 00:03.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge +> 00:04.0 Ethernet controller: Red Hat, Inc. Virtio network device +> 00:05.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI +> 00:06.0 Communication controller: Red Hat, Inc. Virtio console +> 00:10.0 RAM memory: Red Hat, Inc. Inter-VM shared memory (rev 01) +> 01:07.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge +> +> +> *From:* sean kuo <email address hidden> +> *Date:* 2021-03-02 11:24 +> *To:* qemu-devel <email address hidden> +> *Subject:* [Bug 1917394] [NEW] command lspci does not show the IVSHMEM +> device +> Public bug reported: +> +> qeum version: +> QEMU emulator version 4.2.1 +> +> I met a problem when I tried to use IVSHMEM. Command lspci does not show +> the IVSHMEM device. +> Below is the configuration from my side: +> +> 1. guest vm xml configuration. +> <shmem name='ivshmem'> +> <model type='ivshmem-plain'/> +> <size unit='M'>2</size> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x10' +> function='0x0'/> +> </shmem> +> +> 2. after the booting up and I found the qemu commandline ideedly have the +> device option: +> ps aux | grep ivshmem +> /usr/bin/qemu-system-x86_64 +> .......(ignore other options) +> -object +> memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes +> -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 +> +> 3. lspci command not shown the device. +> +> 4. lshw command indeedly show the device: +> +> *-memory UNCLAIMED +> description: RAM memory +> product: Inter-VM shared memory +> vendor: Red Hat, Inc. +> physical id: 10 +> bus info: pci@0000:00:10.0 +> version: 01 +> width: 64 bits +> clock: 33MHz (30.3ns) +> configuration: latency=0 +> resources: memory:fcc1c000-fcc1c0ff memory:fdc00000-fdffffff +> +> My host and vm os is ubuntu 20.04 and version is: +> #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 +> GNU/Linux +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1917394 +> +> Title: +> command lspci does not show the IVSHMEM device +> +> Status in QEMU: +> New +> +> Bug description: +> qeum version: +> QEMU emulator version 4.2.1 +> +> I met a problem when I tried to use IVSHMEM. Command lspci does not show +> the IVSHMEM device. +> Below is the configuration from my side: +> +> 1. guest vm xml configuration. +> <shmem name='ivshmem'> +> <model type='ivshmem-plain'/> +> <size unit='M'>2</size> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x10' +> function='0x0'/> +> </shmem> +> +> 2. after the booting up and I found the qemu commandline ideedly have +> the device option: +> ps aux | grep ivshmem +> /usr/bin/qemu-system-x86_64 +> .......(ignore other options) +> -object +> memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes +> -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 +> +> 3. lspci command not shown the device. +> +> 4. lshw command indeedly show the device: +> +> *-memory UNCLAIMED +> description: RAM memory +> product: Inter-VM shared memory +> vendor: Red Hat, Inc. +> physical id: 10 +> bus info: pci@0000:00:10.0 +> version: 01 +> width: 64 bits +> clock: 33MHz (30.3ns) +> configuration: latency=0 +> resources: memory:fcc1c000-fcc1c0ff memory:fdc00000-fdffffff +> +> My host and vm os is ubuntu 20.04 and version is: +> #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 +> GNU/Linux +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1917394/+subscriptions +> +> +> + + +Thanks so much ChangLimin! You saved me a lot of time. + + +Thanks, +Sean + +On Tue, Mar 2, 2021 at 4:15 PM ChangLimin <email address hidden> wrote: + +> There is no driver for it. You should write it by youself. Maybe you can +> refer to +> http://doc.dpdk.org/guides-1.8/prog_guide/ivshmem_lib.html and dpdk +> source. +> +> Gool luck! +> +> +> *From:* Sean Kuo <email address hidden> +> *Date:* 2021-03-02 15:59 +> *To:* ChangLimin <email address hidden> +> *CC:* Bug 1917394 <email address hidden>; qemu-devel +> <email address hidden> +> *Subject:* Re: [Bug 1917394] [NEW] command lspci does not show the +> IVSHMEM device +> Hi ChangLimin, +> +> Thanks for your reply. I checked again to find the device... I thought the +> name was ivshmem. +> I don't find any driver code for IVSHMEM in the linux and qemu repo. Can +> you give me some help? +> +> 00:10.0 RAM memory: Red Hat, Inc. Inter-VM shared memory (rev 01) +> Subsystem: Red Hat, Inc. QEMU Virtual Machine +> Flags: fast devsel +> Memory at fcc1c000 (32-bit, non-prefetchable) [size=256] +> Memory at fdc00000 (64-bit, prefetchable) [size=4M] +> +> Thanks, +> Sean +> +> +> +> +> +> +> On Tue, Mar 2, 2021 at 3:31 PM ChangLimin <email address hidden> wrote: +> +>> Can you give the lspci messages? The below is my output. There is a RAM +>> memory device. +>> +>> $ lspci +>> 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev +>> 02) +>> 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] +>> 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton +>> II] +>> 00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB +>> [Natoma/Triton II] (rev 01) +>> 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) +>> 00:02.0 VGA compatible controller: Device 1234:1111 (rev 02) +>> 00:03.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge +>> 00:04.0 Ethernet controller: Red Hat, Inc. Virtio network device +>> 00:05.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI +>> 00:06.0 Communication controller: Red Hat, Inc. Virtio console +>> 00:10.0 RAM memory: Red Hat, Inc. Inter-VM shared memory (rev 01) +>> 01:07.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge +>> +>> +>> *From:* sean kuo <email address hidden> +>> *Date:* 2021-03-02 11:24 +>> *To:* qemu-devel <email address hidden> +>> *Subject:* [Bug 1917394] [NEW] command lspci does not show the IVSHMEM +>> device +>> Public bug reported: +>> +>> qeum version: +>> QEMU emulator version 4.2.1 +>> +>> I met a problem when I tried to use IVSHMEM. Command lspci does not show +>> the IVSHMEM device. +>> Below is the configuration from my side: +>> +>> 1. guest vm xml configuration. +>> <shmem name='ivshmem'> +>> <model type='ivshmem-plain'/> +>> <size unit='M'>2</size> +>> <address type='pci' domain='0x0000' bus='0x00' slot='0x10' +>> function='0x0'/> +>> </shmem> +>> +>> 2. after the booting up and I found the qemu commandline ideedly have +>> the device option: +>> ps aux | grep ivshmem +>> /usr/bin/qemu-system-x86_64 +>> .......(ignore other options) +>> -object +>> memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes +>> -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 +>> +>> 3. lspci command not shown the device. +>> +>> 4. lshw command indeedly show the device: +>> +>> *-memory UNCLAIMED +>> description: RAM memory +>> product: Inter-VM shared memory +>> vendor: Red Hat, Inc. +>> physical id: 10 +>> bus info: pci@0000:00:10.0 +>> version: 01 +>> width: 64 bits +>> clock: 33MHz (30.3ns) +>> configuration: latency=0 +>> resources: memory:fcc1c000-fcc1c0ff memory:fdc00000-fdffffff +>> +>> My host and vm os is ubuntu 20.04 and version is: +>> #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 +>> GNU/Linux +>> +>> ** Affects: qemu +>> Importance: Undecided +>> Status: New +>> +>> -- +>> You received this bug notification because you are a member of qemu- +>> devel-ml, which is subscribed to QEMU. +>> https://bugs.launchpad.net/bugs/1917394 +>> +>> Title: +>> command lspci does not show the IVSHMEM device +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> qeum version: +>> QEMU emulator version 4.2.1 +>> +>> I met a problem when I tried to use IVSHMEM. Command lspci does not +>> show the IVSHMEM device. +>> Below is the configuration from my side: +>> +>> 1. guest vm xml configuration. +>> <shmem name='ivshmem'> +>> <model type='ivshmem-plain'/> +>> <size unit='M'>2</size> +>> <address type='pci' domain='0x0000' bus='0x00' slot='0x10' +>> function='0x0'/> +>> </shmem> +>> +>> 2. after the booting up and I found the qemu commandline ideedly have +>> the device option: +>> ps aux | grep ivshmem +>> /usr/bin/qemu-system-x86_64 +>> .......(ignore other options) +>> -object +>> memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes +>> -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 +>> +>> 3. lspci command not shown the device. +>> +>> 4. lshw command indeedly show the device: +>> +>> *-memory UNCLAIMED +>> description: RAM memory +>> product: Inter-VM shared memory +>> vendor: Red Hat, Inc. +>> physical id: 10 +>> bus info: pci@0000:00:10.0 +>> version: 01 +>> width: 64 bits +>> clock: 33MHz (30.3ns) +>> configuration: latency=0 +>> resources: memory:fcc1c000-fcc1c0ff +>> memory:fdc00000-fdffffff +>> +>> My host and vm os is ubuntu 20.04 and version is: +>> #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 +>> GNU/Linux +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1917394/+subscriptions +>> +>> +>> + + +Sounds like this question has been solved, thus I'm closing this ticket now. + diff --git a/results/classifier/118/graphic/1919 b/results/classifier/118/graphic/1919 new file mode 100644 index 000000000..b7be58cf2 --- /dev/null +++ b/results/classifier/118/graphic/1919 @@ -0,0 +1,50 @@ +graphic: 0.980 +device: 0.906 +boot: 0.875 +peripherals: 0.861 +performance: 0.852 +architecture: 0.828 +socket: 0.805 +semantic: 0.761 +mistranslation: 0.713 +user-level: 0.701 +network: 0.687 +PID: 0.673 +debug: 0.661 +permissions: 0.616 +x86: 0.615 +arm: 0.492 +VMM: 0.488 +ppc: 0.486 +kernel: 0.476 +virtual: 0.429 +vnc: 0.315 +TCG: 0.305 +register: 0.226 +files: 0.226 +risc-v: 0.210 +hypervisor: 0.196 +assembly: 0.144 +i386: 0.123 +KVM: 0.106 + +UEFI SecureCode hangs on MacOs - 8.1.1 / MacOS Ventura +Description of problem: +Unable to load edk2 secure boot UEFI code. Non-secure edk2 bios works fine, but secure one hangs during load. +Steps to reproduce: +1. Run mentioned command - it should display OVMF logo - but it hangs +Additional information: +* edk2-x86_64-code.fd works fine, edk2-x86_64-secure-code.fd not +* Tested with swtpm and without - doesn't matter +* TPM access has been observed (when swtpm enabled) - sounds like secure-code validation partially works + +To enable TPM: +``` + -chardev socket,id=chrtpm,path=mytpm0/swtpm-sock \ + -tpmdev emulator,id=tpm0,chardev=chrtpm \ + -device tpm-tis,tpmdev=tpm0 \ +``` +and run swtpm +``` +swtpm socket --tpm2 --tpmstate dir=mytpm0 --ctrl type=unixio,path=mytpm0/swtpm-sock +``` diff --git a/results/classifier/118/graphic/1920 b/results/classifier/118/graphic/1920 new file mode 100644 index 000000000..9f9dbddb6 --- /dev/null +++ b/results/classifier/118/graphic/1920 @@ -0,0 +1,41 @@ +graphic: 0.966 +architecture: 0.930 +device: 0.838 +ppc: 0.695 +performance: 0.660 +arm: 0.645 +network: 0.616 +vnc: 0.593 +semantic: 0.555 +PID: 0.468 +mistranslation: 0.459 +VMM: 0.454 +debug: 0.449 +socket: 0.440 +files: 0.424 +permissions: 0.388 +register: 0.382 +boot: 0.314 +risc-v: 0.291 +TCG: 0.290 +user-level: 0.250 +virtual: 0.248 +x86: 0.197 +peripherals: 0.135 +kernel: 0.089 +hypervisor: 0.087 +i386: 0.062 +KVM: 0.041 +assembly: 0.014 + +regrssion on 8.1.x: java/maven fails to run on qemu-aarch64 +Description of problem: +Java process crashes when running simple "mvn -version" command inside qemu-aarch64. "java -version" works. +Last known working version: 8.0.3 (qemu-8.0.3-4.fc39) +Failing versions: 8.1.1 (qemu-8.1.1-1.fc39) and 8.1.0 (qemu-8.1.0-1.fc39) +The same image works on native arm64 machine. +Steps to reproduce: +1. podman run --platform linux/arm64 docker.io/library/maven:3.9-eclipse-temurin-20 mvn -version +2. should display few lines of version information and not a NullPointerException +Additional information: +podman version 4.7.0 diff --git a/results/classifier/118/graphic/1920871 b/results/classifier/118/graphic/1920871 new file mode 100644 index 000000000..15a43b10f --- /dev/null +++ b/results/classifier/118/graphic/1920871 @@ -0,0 +1,114 @@ +graphic: 0.953 +hypervisor: 0.948 +user-level: 0.944 +mistranslation: 0.935 +permissions: 0.923 +performance: 0.917 +virtual: 0.913 +peripherals: 0.904 +architecture: 0.898 +debug: 0.895 +vnc: 0.892 +network: 0.887 +assembly: 0.880 +ppc: 0.878 +register: 0.870 +VMM: 0.867 +semantic: 0.862 +risc-v: 0.859 +device: 0.851 +PID: 0.835 +files: 0.828 +TCG: 0.823 +boot: 0.820 +kernel: 0.813 +arm: 0.805 +KVM: 0.756 +socket: 0.752 +x86: 0.673 +i386: 0.472 + +netperf UDP_STREAM high packet loss on QEMU tap network + +Hi, I boot a guest with "-netdev tap,id=hn0,vhost=off,br=br0,helper=/usr/local/libexec/qemu-bridge-helper" network option, and using "netperf -H IP -t UDP_STREAM" to test guest UDP performance, I got the following output: + +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 65507 10.00 144710 0 7583.56 +212992 10.00 32 1.68 + +We can find most of UDP packets are lost. But I test another host machine or use "-netdev usr,xxxxx". I can got: +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 65507 10.00 18351 0 961.61 +212992 10.00 18350 961.56 + +most of UDP packets are recived. + +And If we check the tap qemu used, we can see: +ifconfig tap0 +tap0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500 + inet6 fe80::ecc6:21ff:fe6f:b174 prefixlen 64 scopeid 0x20<link> + ether ee:c6:21:6f:b1:74 txqueuelen 1000 (Ethernet) + RX packets 282 bytes 30097 (29.3 KiB) + RX errors 0 dropped 0 overruns 0 frame 0 + TX packets 9086214 bytes 12731596673 (11.8 GiB) + TX errors 0 dropped 16349024 overruns 0 carrier 0 collisions 0 +lots of TX packets are dropped. + +list other packet size: + +➜ boot netperf -H 192.168.199.200 -t UDP_STREAM -- -m 1 +MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.199.200 () port 0 AF_INET +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 1 10.00 2297941 0 1.84 +212992 10.00 1462024 1.17 + +➜ boot netperf -H 192.168.199.200 -t UDP_STREAM -- -m 128 +MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.199.200 () port 0 AF_INET +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 128 10.00 2311547 0 236.70 +212992 10.00 1359834 139.25 + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1920934 b/results/classifier/118/graphic/1920934 new file mode 100644 index 000000000..c6e5d9ddf --- /dev/null +++ b/results/classifier/118/graphic/1920934 @@ -0,0 +1,205 @@ +graphic: 0.883 +hypervisor: 0.877 +peripherals: 0.864 +semantic: 0.817 +virtual: 0.810 +TCG: 0.802 +permissions: 0.800 +device: 0.778 +arm: 0.767 +debug: 0.760 +mistranslation: 0.758 +network: 0.757 +x86: 0.753 +socket: 0.751 +VMM: 0.746 +ppc: 0.742 +vnc: 0.742 +performance: 0.729 +PID: 0.728 +boot: 0.725 +architecture: 0.714 +kernel: 0.694 +register: 0.687 +risc-v: 0.677 +user-level: 0.646 +assembly: 0.579 +i386: 0.471 +files: 0.439 +KVM: 0.437 + +Heap-use-after-free in io_writex / cputlb.c results in Linux kernel crashes + +qemu version: git 5ca634afcf83215a9a54ca6e66032325b5ffb5f6; 5.2.0 + +We've encountered that booting the Linux kernel in TCG mode, results in a racy heap-use-after-free. The bug can be detected by ASan [A], but in the majority of runs results in a crashing kernel [B]. + +To reproduce, the following command line was used: + +$> while ./qemu-system-x86_64 -no-reboot -smp 10 -m 2G -kernel arch/x86/boot/bzImage -nographic -append "oops=panic panic_on_warn=1 panic=1 kfence.sample_interval=1 nokaslr"; do sleep 0.5s; done + +The crashes in the kernel [B] appear to receive an interrupt in a code location where the instructions are periodically patched (via the jump_label infrastructure). + +[A]: +================================================================= +==3552508==ERROR: AddressSanitizer: heap-use-after-free on address 0x6190007fef50 at pc 0x55885b0b4d1b bp 0x7f83baffb800 sp 0x7f83baffb7f8 +READ of size 8 at 0x6190007fef50 thread T4 +[ 4.616506][ T1] pci 0000:00:02.0: reg 0x18: [mem 0xfebf0000-0xfebf0fff] +[ 4.670567][ T1] pci 0000:00:02.0: reg 0x30: [mem 0xfebe0000-0xfebeffff pref] +[ 4.691345][ T1] pci 0000:00:03.0: [8086:100e] type 00 class 0x020000 +[ 4.701540][ T1] pci 0000:00:03.0: reg 0x10: [mem 0xfebc0000-0xfebdffff] +[ 4.711076][ T1] pci 0000:00:03.0: reg 0x14: [io 0xc000-0xc03f] +[ 4.746869][ T1] pci 0000:00:03.0: reg 0x30: [mem 0xfeb80000-0xfebbffff pref] +[ 4.813612][ T1] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) + #0 0x55885b0b4d1a in io_writex ../accel/tcg/cputlb.c:1408 + #1 0x55885b0d3b9f in store_helper ../accel/tcg/cputlb.c:2444 + #2 0x55885b0d3b9f in helper_le_stl_mmu ../accel/tcg/cputlb.c:2510 +[ 4.820927][ T1] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11) + #3 0x7f843cedf8dc (<unknown module>) + +0x6190007fef50 is located 208 bytes inside of 1024-byte region [0x6190007fee80,0x6190007ff280) +freed by thread T11 here: + #0 0x7f8483f431f8 in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:164 + #1 0x7f8483586de7 in g_realloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57de7) + +previously allocated by thread T11 here: + #0 0x7f8483f431f8 in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:164 + #1 0x7f8483586de7 in g_realloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57de7) + +Thread T4 created by T0 here: +[ 4.827679][ T1] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11) +[ 4.835143][ T1] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11) +[ 4.838441][ T1] ACPI: PCI Interrupt Link [LNKS] (IRQs *9) + #0 0x7f8483eee2a2 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cpp:214 + #1 0x55885b7cf0de in qemu_thread_create ../util/qemu-thread-posix.c:558 + +Thread T11 created by T0 here: + #0 0x7f8483eee2a2 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cpp:214 + #1 0x55885b7cf0de in qemu_thread_create ../util/qemu-thread-posix.c:558 + +SUMMARY: AddressSanitizer: heap-use-after-free ../accel/tcg/cputlb.c:1408 in io_writex +Shadow bytes around the buggy address: + 0x0c32800f7d90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c32800f7da0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0x0c32800f7db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c32800f7dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c32800f7dd0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +=>0x0c32800f7de0: fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd + 0x0c32800f7df0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800f7e00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800f7e10: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800f7e20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800f7e30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb + Shadow gap: cc +==3552508==ABORTING + + +[B]: +[ 6.029269][ C4] int3: 0000 [#1] PREEMPT SMP +[ 6.029269][ C4] CPU: 4 PID: 34 Comm: cpuhp/4 Not tainted 5.12.0-rc4 #2 +[ 6.029269][ C4] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 +[ 6.029269][ C4] RIP: 0010:kmem_cache_alloc_trace+0xdd/0x2f0 +[ 6.029269][ C4] Code: de e8 a7 2e 02 00 85 c0 74 0d 48 89 ef e8 bb 60 00 00 e9 e3 00 00 00 4d 85 f6 0f 84 da 00 00 00 4c 89 6c 24 08 48 8b 2c 24 cc <98> 01 00 00 45 31 ed 4c 89 6c 24 10 4d 85 ed 0f 85 99 00 00 00 49 +[ 6.029269][ C4] RSP: 0018:ffffc90000483cc0 EFLAGS: 00000286 +[ 6.029269][ C4] RAX: 0000000000000000 RBX: 0000000000000dc0 RCX: ffff888003b717c0 +[ 6.029269][ C4] RDX: 0000000000000000 RSI: 0000000000000dc0 RDI: ffff888003842a00 +[ 6.029269][ C4] RBP: 0000000000000110 R08: 0000000000000000 R09: 0000000000000000 +[ 6.029269][ C4] R10: ffffffff81248e22 R11: 00000000fa83b201 R12: 0000000000000dc0 +[ 6.029269][ C4] R13: 0000000000000000 R14: ffff888003842a00 R15: ffffffff8150e1c9 +[ 6.029269][ C4] FS: 0000000000000000(0000) GS:ffff88803ea00000(0000) knlGS:0000000000000000 +[ 6.029269][ C4] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 6.029269][ C4] CR2: 0000000000000000 CR3: 0000000002011000 CR4: 00000000000006e0 +[ 6.029269][ C4] Call Trace: +[ 6.029269][ C4] device_add+0x59/0x7b0 +[ 6.029269][ C4] device_create+0xea/0x130 +[ 6.029269][ C4] ? cpu_report_death+0x40/0x40 +[ 6.029269][ C4] ? cpu_report_death+0x40/0x40 +[ 6.029269][ C4] ? msr_devnode+0x20/0x20 +[ 6.029269][ C4] msr_device_create+0x28/0x40 +[ 6.029269][ C4] cpuhp_invoke_callback+0x140/0x2f0 +[ 6.029269][ C4] ? finish_task_switch+0x8c/0x230 +[ 6.029269][ C4] ? cpu_report_death+0x40/0x40 +[ 6.029269][ C4] cpuhp_thread_fun+0x118/0x1a0 +[ 6.029269][ C4] ? cpu_report_death+0x40/0x40 +[ 6.029269][ C4] smpboot_thread_fn+0x1b9/0x270 +[ 6.029269][ C4] kthread+0x14b/0x160 +[ 6.029269][ C4] ? kthread_unuse_mm+0xf0/0xf0 +[ 6.029269][ C4] ret_from_fork+0x1f/0x30 +[ 6.029269][ C4] ---[ end trace 1336f71544bb94e4 ]--- + + + +Does this repro with current-head-of-git QEMU ? + + +Yes, I have: + +commit 5ca634afcf83215a9a54ca6e66032325b5ffb5f6 (HEAD -> master, origin/master, origin/HEAD) +Merge: c95bd5ff16 cffb446e8f +Author: Peter Maydell <email address hidden> +Date: Mon Mar 22 18:50:25 2021 +0000 + +Or another branch? + +This suggests that the rcu_read in iotlb_to_section is not +playing well with one of the g_renew calls in softmmu/physmem.c. + +Not sure which, since the sanitizer dump above doesn't trace +back beyond glib itself. + +I have been unable to reproduce this problem with qemu +master (67c1115edd98), and linux 5.10 w/ your config. + +The config is from 5.12-rc4, and the earliest kernel version that should reproduce this is 5.12-rc1. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1922 b/results/classifier/118/graphic/1922 new file mode 100644 index 000000000..bb3797721 --- /dev/null +++ b/results/classifier/118/graphic/1922 @@ -0,0 +1,50 @@ +graphic: 0.838 +performance: 0.750 +architecture: 0.745 +virtual: 0.685 +device: 0.584 +kernel: 0.576 +semantic: 0.541 +x86: 0.444 +boot: 0.427 +debug: 0.410 +ppc: 0.404 +PID: 0.325 +network: 0.284 +mistranslation: 0.278 +vnc: 0.252 +assembly: 0.192 +risc-v: 0.142 +user-level: 0.137 +socket: 0.131 +TCG: 0.127 +arm: 0.127 +VMM: 0.120 +register: 0.109 +hypervisor: 0.108 +files: 0.101 +i386: 0.083 +permissions: 0.072 +peripherals: 0.062 +KVM: 0.053 + +loongson3-virt machine fails to bring up secondary CPUs +Description of problem: +When booting Debian netboot on `loongson3-virt` machine with SMP, cores other than number 0 fail to come up. Boot without SMP is successful. + +I provided the details of the first combination I tested, but I have also tested on an x86_64 host, as well as with Debian 11 (kernel `5.10.0-22-loongson-3`) on both hosts, with the same results. +Steps to reproduce: +1. `wget https://ftp.debian.org/debian/dists/bookworm/main/installer-mips64el/current/images/loongson-3/netboot/vmlinuz-6.1.0-10-loongson-3` +2. `wget https://ftp.debian.org/debian/dists/bookworm/main/installer-mips64el/current/images/loongson-3/netboot/initrd.gz` +3. `qemu-system-mips64el -M loongson3-virt -kernel vmlinuz-6.1.0-10-loongson-3 -initrd initrd.gz -append "console=ttyS0" -serial stdio -smp 2` +Additional information: +Boot is successful when removing `-smp 2` from command line. With it present, the following error is in `dmesg` (extends to all other CPUs when a larger SMP value is passed): +``` +[ 2.248229] rcu: Hierarchical SRCU implementation. +[ 2.248446] rcu: Max phase no-delay instances is 1000. +[ 2.647997] smp: Bringing up secondary CPUs ... +[ 2.749706] Booting CPU#1... +[ 7.093229] CPU1: failed to start +[ 7.096508] smp: Brought up 1 node, 1 CPU +``` +The boot eventually stalls after this. diff --git a/results/classifier/118/graphic/1922625 b/results/classifier/118/graphic/1922625 new file mode 100644 index 000000000..6b1e7c71a --- /dev/null +++ b/results/classifier/118/graphic/1922625 @@ -0,0 +1,72 @@ +graphic: 0.808 +device: 0.768 +permissions: 0.723 +performance: 0.689 +kernel: 0.686 +files: 0.652 +network: 0.643 +socket: 0.635 +peripherals: 0.582 +mistranslation: 0.541 +architecture: 0.519 +assembly: 0.488 +PID: 0.478 +ppc: 0.456 +arm: 0.454 +hypervisor: 0.452 +x86: 0.442 +boot: 0.423 +i386: 0.394 +semantic: 0.381 +register: 0.371 +vnc: 0.358 +debug: 0.314 +risc-v: 0.297 +KVM: 0.278 +VMM: 0.275 +user-level: 0.255 +TCG: 0.236 +virtual: 0.225 + +qemu 5.2.0 configure script explodes when in read only directory + +I extracted the qemu 5.2.0 source as one user, and then tried to run `./configure --help` in that directory as a different user. Normal autoconf configure scripts have no problem with this but yours goes into an infinite loop printing nonsense: + +Using './build' as the directory for build output +mkdir: build: Permission denied +touch: build/auto-created-by-configure: No such file or directory +./configure: line 37: GNUmakefile: Permission denied +./configure: line 59: cd: build: No such file or directory +Using './build' as the directory for build output +mkdir: build: Permission denied +touch: build/auto-created-by-configure: No such file or directory +/path/to/qemu-5.2.0/configure: line 37: GNUmakefile: Permission denied +/path/to/qemu-5.2.0/configure: line 59: cd: build: No such file or directory +Using './build' as the directory for build output +mkdir: build: Permission denied +touch: build/auto-created-by-configure: No such file or directory +/path/to/qemu-5.2.0/configure: line 37: GNUmakefile: Permission denied +/path/to/qemu-5.2.0/configure: line 59: cd: build: No such file or directory +Using './build' as the directory for build output +mkdir: build: Permission denied +touch: build/auto-created-by-configure: No such file or directory +/path/to/qemu-5.2.0/configure: line 37: GNUmakefile: Permission denied +/path/to/qemu-5.2.0/configure: line 59: cd: build: No such file or directory +Using './build' as the directory for build output +mkdir: build: Permission denied +touch: build/auto-created-by-configure: No such file or directory +/path/to/qemu-5.2.0/configure: line 37: GNUmakefile: Permission denied +/path/to/qemu-5.2.0/configure: line 59: cd: build: No such file or directory +Using './build' as the directory for build output +mkdir: build: Permission denied + +etc. + + +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/321 + + diff --git a/results/classifier/118/graphic/1923 b/results/classifier/118/graphic/1923 new file mode 100644 index 000000000..ca83444d1 --- /dev/null +++ b/results/classifier/118/graphic/1923 @@ -0,0 +1,48 @@ +graphic: 0.960 +files: 0.925 +device: 0.925 +network: 0.869 +VMM: 0.810 +PID: 0.760 +register: 0.755 +architecture: 0.747 +kernel: 0.701 +performance: 0.670 +semantic: 0.630 +debug: 0.600 +risc-v: 0.592 +vnc: 0.569 +mistranslation: 0.563 +boot: 0.529 +permissions: 0.528 +socket: 0.513 +x86: 0.497 +i386: 0.486 +arm: 0.455 +peripherals: 0.441 +ppc: 0.424 +KVM: 0.417 +TCG: 0.398 +virtual: 0.377 +assembly: 0.330 +hypervisor: 0.317 +user-level: 0.281 + +qemu breaks vmdk larger than 600GB. +Description of problem: +The vmdk larger than 600G is corrupted after an edit by qemu-nbd. If I open the corrupted vmdk file, I find an extra **^@** byte. +``` +RW 4194304 SPARSE "disk-s289.vmdk" +RW 4^@94304 SPARSE "disk-s290.vmdk" +RW 4194304 SPARSE "disk-s291.vmdk" +``` +Steps to reproduce: +``` + qemu-img create -f vmdk -o subformat=twoGbMaxExtentSparse disk.vmdk 1T + sudo qemu-nbd -c /dev/nbd0 disk.vmdk + sudo mkfs.btrfs /dev/nbd0 + sudo qemu-nbd -d /dev/nbd0 + qemu-img info disk.vmdk | head + ``` +Additional information: + diff --git a/results/classifier/118/graphic/1924738 b/results/classifier/118/graphic/1924738 new file mode 100644 index 000000000..525588c0f --- /dev/null +++ b/results/classifier/118/graphic/1924738 @@ -0,0 +1,104 @@ +graphic: 0.910 +semantic: 0.885 +user-level: 0.815 +performance: 0.801 +virtual: 0.791 +ppc: 0.783 +architecture: 0.781 +mistranslation: 0.777 +debug: 0.760 +assembly: 0.740 +permissions: 0.739 +register: 0.698 +arm: 0.687 +risc-v: 0.687 +device: 0.677 +peripherals: 0.674 +KVM: 0.673 +VMM: 0.665 +kernel: 0.656 +PID: 0.653 +TCG: 0.635 +network: 0.634 +hypervisor: 0.632 +socket: 0.627 +x86: 0.591 +files: 0.591 +vnc: 0.589 +boot: 0.573 +i386: 0.267 + +Failed to restore domain - error load load virtio-balloon:virtio + +I noticed a domain restore error on my virtual machines. +I can't reproduce the error on a test virtual machine. + +sudo virsh save linux2020 /var/lib/libvirt/qemu/save/linux2020.save +Domain 'linux2020' saved to /var/lib/libvirt/qemu/save/linux2020.save + +sudo virsh restore /var/lib/libvirt/qemu/save/linux2020.save +error: Failed to restore domain from /var/lib/libvirt/qemu/save/linux2020.save +error: внутренняя ошибка: QEMU неожиданно завершил работу монитора: qemu-system-x86_64: -chardev socket,id=charchannel0,fd=52,server,nowait: warning: short-form boolean option 'server' deprecated +Please use server=on instead +qemu-system-x86_64: -chardev socket,id=charchannel0,fd=52,server,nowait: warning: short-form boolean option 'nowait' deprecated +Please use wait=off instead +qemu-system-x86_64: -spice port=5900,addr=0.0.0.0,disable-ticketing,image-compression=off,seamless-migration=on: warning: short-form boolean option 'disable-ticketing' deprecated +Please use disable-ticketing=on instead +2021-04-16T09:47:15.037700Z qemu-system-x86_64: VQ 0 size 0x80 < last_avail_idx 0x0 - used_idx 0xcccc +2021-04-16T09:47:15.037737Z qemu-system-x86_64: Failed to load virtio-balloon:virtio +2021-04-16T09:47:15.037744Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:02.0/virtio-balloon' +2021-04-16T09:47:15.037849Z qemu-system-x86_64: load of migration failed: Operation not permitted + +If in the machine configuration replace +<type arch="x86_64" machine="pc-i440fx-5.1">hvm</type> +to +<type arch="x86_64" machine="pc-i440fx-5.0">hvm</type> +the virtual machine is recovering normally + + + +Can you just clarify: + a) Which version of qemu are you running? + b) Was the save done with the pc-i440fx-5.1 as well as the load? + c) What guest are you running? + +a) Checked for versions 5.2.0 and 6.0.0rc. +b) Save and restore with pc-i440fx-5.1. +c) Used OS Linux NixOS Unstable. +If clean install NixOS system - the error is not reproduced. It was not possible to track what affects the restore domain. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know how to transfer the bug to the new system if +(if still necessary). Thus we're setting the status to "Incomplete" now. + +In the unlikely case that the bug has already been fixed in the final +6.0 release version of QEMU, then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here should be +moved to the new system, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + +Ticket has been re-opened here : +https://gitlab.com/qemu-project/qemu/-/issues/485 + diff --git a/results/classifier/118/graphic/1924987 b/results/classifier/118/graphic/1924987 new file mode 100644 index 000000000..0fbca47a7 --- /dev/null +++ b/results/classifier/118/graphic/1924987 @@ -0,0 +1,75 @@ +graphic: 0.883 +virtual: 0.870 +x86: 0.787 +files: 0.781 +architecture: 0.761 +mistranslation: 0.737 +device: 0.698 +performance: 0.688 +user-level: 0.687 +hypervisor: 0.629 +i386: 0.616 +semantic: 0.611 +permissions: 0.592 +register: 0.570 +network: 0.519 +PID: 0.514 +ppc: 0.513 +kernel: 0.496 +peripherals: 0.462 +vnc: 0.452 +debug: 0.444 +arm: 0.428 +VMM: 0.419 +TCG: 0.384 +socket: 0.358 +assembly: 0.356 +risc-v: 0.328 +boot: 0.311 +KVM: 0.305 + +Storage | Two decimal digits precision + +Tested on: Fedora 34; Component: qemu-img-5.2.0-5.fc34.1.x86_64 + +Hello. A two decimal digits precision is most appropriated on systems whose storage capacities have to be saved. That is one of the reason why such precision is supported in the context of creation of virtual machines in several Unix/Linux virtualization platforms; virt-manager is one of them. That last exhibits virtual disks size values with such precision – 128.00 GiB – nevertheless it lacks yet a mention illustrating physical disks size values. + +Storage values exhibited in qemu-img and virt-manager are already according to a clear format; thus, values are not attached to their measure units (#value# #units#). + +$ qemu-img info ~/.local/share/libvirt/images/fedora_default.img | sed -n '2,4p' +file format: qcow2 +virtual size: 128 GiB (137438953472 bytes) +disk size: 147 MiB + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1925109 b/results/classifier/118/graphic/1925109 new file mode 100644 index 000000000..c4bcd5802 --- /dev/null +++ b/results/classifier/118/graphic/1925109 @@ -0,0 +1,80 @@ +graphic: 0.854 +semantic: 0.826 +device: 0.819 +architecture: 0.818 +mistranslation: 0.808 +peripherals: 0.800 +x86: 0.789 +files: 0.789 +performance: 0.786 +user-level: 0.785 +debug: 0.760 +network: 0.740 +permissions: 0.734 +assembly: 0.731 +kernel: 0.729 +PID: 0.723 +hypervisor: 0.703 +arm: 0.702 +ppc: 0.688 +boot: 0.654 +socket: 0.641 +virtual: 0.634 +register: 0.634 +risc-v: 0.608 +VMM: 0.587 +vnc: 0.583 +TCG: 0.562 +i386: 0.559 +KVM: 0.557 + +usbredirparser: bulk transfer length exceeds limits + +2021-04-20T01:26:36.662244Z qemu-system-x86_64: usbredirparser: bulk transfer length exceeds limits 131072 > 65536 +2021-04-20T01:26:36.662276Z qemu-system-x86_64: usbredirparser: error usbredirparser_send_* call invalid params, please report!! +2021-04-20T01:26:57.670412Z qemu-system-x86_64: usbredirparser: bulk transfer length exceeds limits 131072 > 65536 +2021-04-20T01:26:57.670445Z qemu-system-x86_64: usbredirparser: error usbredirparser_send_* call invalid params, please report!! +2021-04-20T01:37:01.920613Z qemu-system-x86_64: usbredirparser: bulk transfer length exceeds limits 131072 > 65536 +2021-04-20T01:37:01.920624Z qemu-system-x86_64: usbredirparser: error usbredirparser_send_* call invalid params, please report!! +host: +Linux version 5.11.15-arch1-2 (linux@archlinux) (gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP PREEMPT Sat, 17 Apr 2021 00:22:30 +0000 +guest: +win10 20H2 +usb device: +Bus 002 Device 007: ID 0781:55ab SanDisk Corp. SanDisk 3.2Gen1 +size 250G + +https://gitlab.freedesktop.org/spice/usbredir/-/blob/master/usbredirparser/usbredirparser.c#L32 + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1925966 b/results/classifier/118/graphic/1925966 new file mode 100644 index 000000000..061b5920d --- /dev/null +++ b/results/classifier/118/graphic/1925966 @@ -0,0 +1,96 @@ +graphic: 0.893 +semantic: 0.875 +user-level: 0.871 +virtual: 0.851 +peripherals: 0.848 +performance: 0.847 +debug: 0.841 +device: 0.838 +permissions: 0.832 +assembly: 0.814 +arm: 0.813 +register: 0.809 +hypervisor: 0.806 +x86: 0.803 +mistranslation: 0.803 +PID: 0.802 +vnc: 0.797 +architecture: 0.795 +risc-v: 0.795 +boot: 0.794 +TCG: 0.789 +ppc: 0.788 +socket: 0.773 +kernel: 0.773 +files: 0.766 +network: 0.763 +VMM: 0.670 +KVM: 0.665 +i386: 0.541 + +Win10 guest freezes randomly + +In addition to bug #1916775, my Win10 Home guest freezes randomly and infrequently. Unlike bug +#1916775, this is unrecoverable and I see on the host (Debian 4.19.171-2) via iotop that all disk IO has stopped. My only recourse is a hard reset of the guest. + +My setup uses PCI-pass-through graphics (GTX 1650), host cpu (Ryzen 7 3800XT). It seems to occur more frequently when I plug in 3 monitors rather than 2 into the pass-through graphics card. It occurs whether or not I use the qcow disk drive. + +qemu-system-x86_64 + -cpu host,kvm=on,l3-cache=on,hv_relaxed,hv_vapic,hv_time,hv_spinlocks=0x1fff,hv_vendor_id=hv_dummy + -smp 8 + -rtc clock=host,base=localtime + -machine type=q35,accel=kvm,kernel_irqchip=on + -enable-kvm + -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd + -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd + -m 32G + -usb + -device usb-tablet + -vga none + -serial none + -parallel none + -boot cd + -nographic + -device usb-host,vendorid=0x045e,productid=0x00db + -device usb-host,vendorid=0x1bcf,productid=0x0005 + -drive id=disk0,index=0,format=qcow2,if=virtio,cache=off,file=./win10_boot_priv.qcow2 + -drive id=disk2,index=2,aio=native,cache.direct=on,if=virtio,cache=off,format=raw,discard=unmap,detect-zeroes=unmap,file=/dev/vg0/win10_hdpriv + -device vfio-pci,host=09:00.0,addr=0x02.0x0,multifunction=on + -device vfio-pci,host=09:00.1,addr=0x02.0x1 + -device vfio-pci,host=09:00.2,addr=0x02.0x2 + -device vfio-pci,host=09:00.3,addr=0x02.0x3 + -netdev tap,id=netid,ifname=taplan,script=no,downscript=no + -device e1000,netdev=netid,mac=52:54:00:01:02:03 + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/1926052 b/results/classifier/118/graphic/1926052 new file mode 100644 index 000000000..20d05bdf6 --- /dev/null +++ b/results/classifier/118/graphic/1926052 @@ -0,0 +1,49 @@ +graphic: 0.913 +architecture: 0.833 +boot: 0.778 +device: 0.760 +performance: 0.637 +x86: 0.536 +semantic: 0.487 +mistranslation: 0.415 +user-level: 0.412 +debug: 0.332 +ppc: 0.277 +network: 0.263 +arm: 0.216 +permissions: 0.202 +socket: 0.200 +vnc: 0.197 +PID: 0.196 +register: 0.192 +i386: 0.184 +virtual: 0.178 +files: 0.175 +kernel: 0.158 +peripherals: 0.122 +TCG: 0.109 +risc-v: 0.096 +assembly: 0.094 +VMM: 0.088 +hypervisor: 0.062 +KVM: 0.028 + +qemu freezes during grub on arch cloudimg + +When booting the Arch Linux cloud image and setting `-nographic`, qemu will freeze during the grub bootloader. +Tested with qemu 5.1 and 5.2. + +Reproduce: +``` +wget https://gitlab.archlinux.org/archlinux/arch-boxes/-/jobs/20342/artifacts/raw/output/Arch-Linux-x86_64-basic-20210420.20342.qcow2 + +qemu-system-x86_64 -hda Arch-Linux-x86_64-basic-20210420.20342.qcow2 -nographic + +``` + +It will get stuck while displaying `Welcome to GRUB!` +If -nographic is omitted, it will continue to boot (without any keyboard interaction) + +Sorry, this is actually not a qemu problem. The arch system just doesn't display any messages during boot when `-nographic` is used. +The issue can be closed. + diff --git a/results/classifier/118/graphic/1937 b/results/classifier/118/graphic/1937 new file mode 100644 index 000000000..15ea77b81 --- /dev/null +++ b/results/classifier/118/graphic/1937 @@ -0,0 +1,41 @@ +graphic: 0.918 +device: 0.749 +performance: 0.690 +network: 0.580 +semantic: 0.387 +debug: 0.277 +virtual: 0.205 +vnc: 0.194 +permissions: 0.187 +risc-v: 0.175 +boot: 0.174 +architecture: 0.163 +kernel: 0.156 +PID: 0.149 +arm: 0.149 +hypervisor: 0.149 +ppc: 0.115 +i386: 0.109 +files: 0.104 +x86: 0.094 +VMM: 0.089 +mistranslation: 0.080 +KVM: 0.062 +TCG: 0.052 +user-level: 0.048 +register: 0.035 +peripherals: 0.025 +assembly: 0.006 +socket: 0.005 + +Live migration with TLS fail (GNUTLS AUTO_REKEY) +Description of problem: +Live migration with TLS fail in postcopy stage when: + +# +Steps to reproduce: +1. run VM with heavy RAM load: `nohup stress-ng --vm 6 --vm-bytes 12G &` +2. run precopy for more that 80sec +3. switch into post-copy stage +Additional information: +This only occurs with TLS transport, if clear qemu+tcp is used then everything works. diff --git a/results/classifier/118/graphic/1942 b/results/classifier/118/graphic/1942 new file mode 100644 index 000000000..9719bdd50 --- /dev/null +++ b/results/classifier/118/graphic/1942 @@ -0,0 +1,39 @@ +graphic: 0.836 +device: 0.745 +PID: 0.521 +ppc: 0.492 +network: 0.433 +user-level: 0.432 +semantic: 0.389 +debug: 0.388 +architecture: 0.377 +vnc: 0.357 +permissions: 0.327 +files: 0.324 +risc-v: 0.310 +socket: 0.281 +arm: 0.279 +boot: 0.273 +performance: 0.252 +TCG: 0.236 +register: 0.218 +virtual: 0.162 +VMM: 0.144 +mistranslation: 0.130 +peripherals: 0.087 +x86: 0.079 +hypervisor: 0.060 +i386: 0.053 +kernel: 0.032 +assembly: 0.031 +KVM: 0.011 + +GCC segfault (ICE) while building in qemu-user sparc64 +Steps to reproduce: +1. Follow Qemu-user [documentation](https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Compiling_with_qemu_user_chroot) for Sparc64 +2. Attempt to build libpaper: `emerge -v app-text/libpaper-2.1.0:0/2` + +Resulting compilation will fail with an internal compilation error. +Additional information: +This can be tested by trying to [compile](/uploads/ba4585ea75fa157a34bf8f3ffb64bded/H1NM.i) with `gcc -mcpu=ultrasparc -O2 -c` instead of building the entire libpaper package. +Here is the [output.](/uploads/30a154eb602caa5a8b1bd82a6271d6d8/output.txt) diff --git a/results/classifier/118/graphic/1943 b/results/classifier/118/graphic/1943 new file mode 100644 index 000000000..3d45d5d76 --- /dev/null +++ b/results/classifier/118/graphic/1943 @@ -0,0 +1,54 @@ +graphic: 0.966 +mistranslation: 0.945 +device: 0.792 +performance: 0.697 +semantic: 0.645 +architecture: 0.598 +PID: 0.548 +socket: 0.487 +kernel: 0.482 +ppc: 0.475 +network: 0.461 +vnc: 0.457 +files: 0.457 +i386: 0.449 +user-level: 0.441 +x86: 0.417 +assembly: 0.405 +register: 0.388 +debug: 0.381 +hypervisor: 0.376 +TCG: 0.371 +KVM: 0.340 +risc-v: 0.334 +arm: 0.295 +boot: 0.293 +VMM: 0.289 +peripherals: 0.286 +virtual: 0.283 +permissions: 0.192 + +Weird error trying to autodetect CHS disk geometry +Description of problem: +Error: "SSD Read Error" + +Something about the contents of the disk causes qemu to wildly misdetect the disk geometry. +This disk started as a blank disk, and had a FAT filesystem written to it from inside it; thus +writing the detected geometry to the disk. And this caused the detected geometry to change to +something nonsensical. +Steps to reproduce: +1. Unpack the attached [hd.bz2](/uploads/53f5bb00cdd563223bea1f7a0f86fe1c/hd.bz2) to hd.img +2. Run qemu -hda hd.img +3. Observe error +Additional information: +The following command appears to fix the problem; however it is wrong: + +qemu -drive if=none,id=dr,file=hd.img -device ide-hd,drive=dr,cyls=1023,heads=16,secs=63 + +The problem with this command is this command yields only 504MB instead of the 512MB the +disk is actually formatted to be. CHS translation should be enabled on this disk but won't +be with this command. + +This command was copied essentially blindly from "Removed features" because that's what comes +up for a google search for "qemu specify geometry" and I don't understand the command well +enough to correct it. diff --git a/results/classifier/118/graphic/1944 b/results/classifier/118/graphic/1944 new file mode 100644 index 000000000..a821e2390 --- /dev/null +++ b/results/classifier/118/graphic/1944 @@ -0,0 +1,101 @@ +graphic: 0.933 +peripherals: 0.930 +permissions: 0.916 +assembly: 0.915 +semantic: 0.908 +architecture: 0.907 +debug: 0.897 +risc-v: 0.889 +register: 0.886 +TCG: 0.883 +ppc: 0.879 +vnc: 0.875 +arm: 0.873 +hypervisor: 0.867 +performance: 0.861 +virtual: 0.855 +x86: 0.851 +VMM: 0.849 +device: 0.848 +PID: 0.840 +i386: 0.838 +user-level: 0.836 +mistranslation: 0.830 +KVM: 0.823 +kernel: 0.805 +network: 0.805 +files: 0.775 +socket: 0.735 +boot: 0.717 + +Deadlock on snapshot removal (bdrv_graph_wrlock) +Description of problem: +VM was hanging during snapshot removal. +There was an attempt to shutdown the VM, but that did hang. + +gdb shows me: +``` +(gdb) bt full +#0 0x00007f20493427fe in __ppoll (fds=0x557e630718b0, nfds=2, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:43 + sc_ret = -514 + sc_cancel_oldtype = 0 + sc_ret = <optimized out> + tval = {tv_sec = 139776632323420, tv_nsec = 139776632323432} +#1 0x0000557e619cab52 in fdmon_poll_wait.llvm () +No symbol table info available. +#2 0x0000557e619ca0b6 in aio_poll () +No symbol table info available. +#3 0x0000557e61801651 in bdrv_graph_wrlock () +No symbol table info available. +#4 0x0000557e617c873b in bdrv_replace_child_noperm.llvm () +No symbol table info available. +#5 0x0000557e617c8601 in bdrv_root_unref_child () +No symbol table info available. +#6 0x0000557e617f6333 in blk_unref () +No symbol table info available. +#7 0x0000557e6181b0d1 in mirror_exit_common () +No symbol table info available. +#8 0x0000557e617dbdb4 in job_do_finalize_locked.llvm () +No symbol table info available. +#9 0x0000557e617dd72b in job_exit () +No symbol table info available. +#10 0x0000557e619e5101 in aio_bh_poll () +No symbol table info available. +#11 0x0000557e619c95a4 in aio_dispatch () +No symbol table info available. +#12 0x0000557e619e655f in aio_ctx_dispatch () +No symbol table info available. +#13 0x00007f2049546e2f in g_main_dispatch (context=0x557e62ecebd0) at ../glib/gmain.c:3337 + dispatch = 0x557e619e6550 <aio_ctx_dispatch> + prev_source = 0x0 + begin_time_nsec = 232172181173336 + was_in_call = <optimized out> + user_data = 0x0 + callback = 0x0 + cb_funcs = 0x0 + cb_data = 0x0 + need_destroy = <optimized out> + source = 0x557e62ec73e0 + current = 0x557e63e4b600 + i = 0 + __func__ = {<optimized out> <repeats 16 times>} +#14 g_main_context_dispatch (context=0x557e62ecebd0) at ../glib/gmain.c:4055 +No locals. +#15 0x0000557e619e74be in main_loop_wait () +No symbol table info available. +#16 0x0000557e615201e7 in qemu_main_loop () +No symbol table info available. +#17 0x0000557e61374c6a in qemu_default_main () +No symbol table info available. +#18 0x00007f204923feb0 in __libc_start_call_main (main=main@entry=0x557e61374c80 <main>, argc=argc@entry=153, argv=argv@entry=0x7ffe07495238) at ../sysdeps/nptl/libc_start_call_main.h:58 + self = <optimized out> + result = <optimized out> + unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -6145724763479124305, 140729020666424, 94001285254272, 94001294953808, 139776661151744, 6145708635144279727, 6121919821307926191}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7f204954cb41 <g_malloc0+33>, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 1230293825}}} + not_first_call = <optimized out> +#19 0x00007f204923ff60 in __libc_start_main_impl (main=0x557e61374c80 <main>, argc=153, argv=0x7ffe07495238, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe07495228) at ../csu/libc-start.c:389 +No locals. +#20 0x0000557e613743d5 in _start () +No symbol table info available. +``` +Steps to reproduce: +Still trying to reproduce in lab. diff --git a/results/classifier/118/graphic/1947 b/results/classifier/118/graphic/1947 new file mode 100644 index 000000000..73a63308f --- /dev/null +++ b/results/classifier/118/graphic/1947 @@ -0,0 +1,50 @@ +graphic: 0.891 +device: 0.782 +semantic: 0.746 +ppc: 0.678 +performance: 0.610 +files: 0.594 +mistranslation: 0.589 +debug: 0.587 +PID: 0.573 +architecture: 0.569 +register: 0.556 +TCG: 0.553 +user-level: 0.541 +boot: 0.533 +arm: 0.504 +permissions: 0.486 +socket: 0.478 +vnc: 0.456 +KVM: 0.447 +risc-v: 0.444 +assembly: 0.431 +x86: 0.408 +peripherals: 0.394 +kernel: 0.325 +i386: 0.245 +virtual: 0.219 +VMM: 0.192 +network: 0.186 +hypervisor: 0.184 + +ACPI (Stop code 0x000000A5) BSOD During Windows XP Professional x64 Edition Setup +Description of problem: +When attempting to launch Windows XP Professional x64 Edition setup, the setup crashes with BSOD stop code 0x000000A5 and the following message: +``` +A problem has been detected and Windows has been shut down to prevent damage to your computer. + +If this is the first time you've seen this Stop error screen, restart your computer. If this screen appears again, follow these steps: + +The BIOS in this system is not fully ACPI compliant. Please contact your system vendor for an updated BIOS. If you are unable to obtain an updated BIOS or the latest BIOS supplied by your vendor is not ACPI compliant, you can turn off ACPI mode during textmode setup. To do this, press the F7 key when you are prompted to install storage drivers. The system will not notify you that the F7 key was pressed - it will silently disable ACPI and allow you to continue your installation. + +Technical information: + +*** STOP: 0x000000A5 (0x0000000000000014, 0xFFFFFA80000CBFC6, 0x000000000000008A, 0xFFFFFADFC8E31A90) +``` +Steps to reproduce: +1. Obtain a copy of Windows XP Professional x64 Edition SP2. +2. Run QEMU using the provided command line (with the name & location of your ISO in place of "Windows XP Professional x64 Edition.iso") +Additional information: +It appears the bug may be dependent on KVM, I've seen some conflicting results, but with the provided command line removing "accel=kvm" or replacing it with "accel=tcg" changes the BSOD to one about lack of disk space. +Also, a similar bug occurs with Windows 2000 SP4, but the setup will hang instead of crash. (The hang can be avoided by pressing F5 and selecting "Standard PC" instead of either ACPI option during setup.) diff --git a/results/classifier/118/graphic/1950 b/results/classifier/118/graphic/1950 new file mode 100644 index 000000000..a60055620 --- /dev/null +++ b/results/classifier/118/graphic/1950 @@ -0,0 +1,39 @@ +architecture: 0.971 +graphic: 0.946 +arm: 0.899 +performance: 0.874 +device: 0.872 +network: 0.860 +files: 0.827 +socket: 0.798 +vnc: 0.776 +kernel: 0.761 +ppc: 0.755 +PID: 0.740 +risc-v: 0.701 +register: 0.700 +TCG: 0.667 +debug: 0.654 +semantic: 0.614 +mistranslation: 0.608 +permissions: 0.588 +VMM: 0.577 +boot: 0.542 +hypervisor: 0.420 +user-level: 0.419 +peripherals: 0.365 +KVM: 0.325 +assembly: 0.290 +virtual: 0.222 +x86: 0.053 +i386: 0.034 + +[AARCH64] GP bit (BTI) lost during two stages translation +Description of problem: +I noticed that the BTI faults were not reported. +That's because the GP (guarded page) information is lost during the two stages translation in get_phys_addr_twostage(). +The "guarded" information is correctly retrieved by the first call to get_phys_addr_nogpc() but overwritten by the the second call to get_phys_addr_nogpc(). +The call to combine_cacheattrs() copies cacheattrs1.guarded but this field is never modified. + +The attached patch fixes the issue for me. +[get_phys_addr_twostage_bti_gp_bit_lost_master.patch](/uploads/2fbe8090f92c43a63e39ee66ab2daf47/get_phys_addr_twostage_bti_gp_bit_lost_master.patch) diff --git a/results/classifier/118/graphic/1954 b/results/classifier/118/graphic/1954 new file mode 100644 index 000000000..f48fe41af --- /dev/null +++ b/results/classifier/118/graphic/1954 @@ -0,0 +1,58 @@ +graphic: 0.982 +performance: 0.884 +PID: 0.874 +semantic: 0.873 +user-level: 0.865 +permissions: 0.851 +VMM: 0.833 +device: 0.825 +risc-v: 0.813 +socket: 0.795 +architecture: 0.782 +peripherals: 0.775 +vnc: 0.770 +TCG: 0.769 +files: 0.745 +arm: 0.726 +network: 0.708 +ppc: 0.705 +debug: 0.701 +mistranslation: 0.693 +virtual: 0.678 +register: 0.670 +x86: 0.667 +assembly: 0.637 +hypervisor: 0.589 +boot: 0.585 +kernel: 0.548 +KVM: 0.477 +i386: 0.314 + +guest-fsfreeze can't work well on windows +Description of problem: +I used qemu 5.0 to cross-compile windows gqa on the fedroa30 system.And install it on guest with windows10,but i can't work well. +Steps to reproduce: +1. ./configure --cross-prefix=x86_64-w64-mingw32- --enable-guest-agent-msi --with-vss-sdk=/root/vssdk/VSSSDK72 + + my vssdk download from:[vssdk](https://www.microsoft.com/en-us/download/details.aspx?id=23490),i install it on my pc and copy to /root/vssdk/VSSSDK72 + +2. make qemu-ga -j4 + +3. and then install qemu-ga-x86_64.msi on windows10,it report the error: +  + +4.then I ./configure not with "--with-vss-sdk",the qemu-ga-x86_64.msi can install successfully. + +5.So, I install gga first. Then ./configure with "--with-vss-sdk" to make get the qemu-ga.exe + +6.replace qemu-ga.exe and reboot gga service,then execute the command "virsh domfsfreeze" on host,but it report error: + + error: Unable to freeze filesystems + error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to add \\?\Volume{d1ee1072-0000-0000-0000-100000000000}\ to snapshot set: + + +**I looked at the windows Event Viewer,it get the error:** + + Unexpected error querying for the IVssWriterCallback interface. hr = 0x80070005, Access is denied. + +I have referred to this [document](https://www.ryadel.com/en/volume-shadow-copy-service-error-unexpected-error-querying-for-the-ivsswritercallback-interface-how-to-fix-that/),but it not work. diff --git a/results/classifier/118/graphic/1962 b/results/classifier/118/graphic/1962 new file mode 100644 index 000000000..b6fcaf55a --- /dev/null +++ b/results/classifier/118/graphic/1962 @@ -0,0 +1,59 @@ +architecture: 0.964 +graphic: 0.932 +performance: 0.816 +files: 0.788 +device: 0.787 +boot: 0.772 +permissions: 0.770 +assembly: 0.750 +PID: 0.713 +register: 0.652 +mistranslation: 0.637 +arm: 0.604 +user-level: 0.592 +kernel: 0.591 +peripherals: 0.558 +socket: 0.544 +semantic: 0.485 +debug: 0.445 +risc-v: 0.422 +network: 0.386 +vnc: 0.361 +ppc: 0.353 +hypervisor: 0.286 +VMM: 0.235 +TCG: 0.173 +virtual: 0.168 +x86: 0.150 +i386: 0.136 +KVM: 0.047 + +systemd-tmpfiles-setup-dev-early.service fails in emulated systemd-nspawn container +Description of problem: +When booting a fresh `debootstrap`ed Debian Trixie/testing rootfs with foreign architecture via `systemd-nspawn` and `qemu-user-static`, invoked via `systemd-binfmt`, the `systemd-tmpfiles-setup-dev-early.service` service within the guest fails, which leads to `/dev` not existing (respectively no default content), so that several other guest system components fail as well, like any console/shell access: +``` +Starting systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully... +systemd-tmpfiles-setup-dev-early.service: Failed to set up credentials: Invalid argument +systemd-tmpfiles-setup-dev-early.service: Main process exited, code=exited, status=243/CREDENTIALS +systemd-tmpfiles-setup-dev-early.service: Failed with result 'exit-code'. +[FAILED] Failed to start systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully. +See 'systemctl status systemd-tmpfiles-setup-dev-early.service' for details. +Starting systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev... +systemd-tmpfiles-setup-dev.service: Failed to set up credentials: Invalid argument +systemd-tmpfiles-setup-dev.service: Main process exited, code=exited, status=243/CREDENTIALS +systemd-tmpfiles-setup-dev.service: Failed with result 'exit-code'. +[FAILED] Failed to start systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev. +See 'systemctl status systemd-tmpfiles-setup-dev.service' for details. +``` +Steps to reproduce: +1. `apt install debootstrap systemd-container qemu-user-static` +2. `systemctl restart systemd-binfmt` +3. `mkdir rootfs` +4. `debootstrap --variant=minbase --include=systemd-sysv --arch=arm64 trixie ./rootfs 'https://deb.debian.org/debian'` +5. `systemd-nspawn -bD rootfs` +Additional information: +On Bookworm guest systems and/or without QEMU emulation, this works without issues, so I guess systemd recently started to use a certain syscall for the `ImportCredential=tmpfiles.*` method in systemd units, which is not supported by QEMU, probably similar to https://github.com/systemd/systemd/pull/28954? + +I hope it is fine to report it here. Always difficult to decide whether to report to the distribution (Debian) or one, and in case which, of the related projects, which do not work together. + +Debian Trixie currently ships `systemd 254.4-1` btw. I am not sure whether the issue was introduced with 253 or 254, since the linked issue prevented booting such containers on an earlier stage with 253, which was fixed in 254, which has the here reported issue. diff --git a/results/classifier/118/graphic/1986 b/results/classifier/118/graphic/1986 new file mode 100644 index 000000000..ca18371a7 --- /dev/null +++ b/results/classifier/118/graphic/1986 @@ -0,0 +1,44 @@ +graphic: 0.900 +performance: 0.886 +semantic: 0.881 +device: 0.870 +architecture: 0.733 +PID: 0.567 +files: 0.534 +peripherals: 0.529 +mistranslation: 0.449 +hypervisor: 0.446 +permissions: 0.402 +user-level: 0.377 +x86: 0.363 +ppc: 0.363 +debug: 0.341 +assembly: 0.339 +network: 0.324 +socket: 0.321 +i386: 0.288 +boot: 0.261 +register: 0.260 +VMM: 0.256 +vnc: 0.244 +risc-v: 0.236 +TCG: 0.234 +virtual: 0.209 +arm: 0.155 +kernel: 0.107 +KVM: 0.062 + +windows install fails with error 0x80070001 +Description of problem: +I have a windows vm executed via libvirt, I run it on a physical drive passing it into the guest. when I pass it via sata pt and try to install windows 11 on it, the install fails with error 0x80070001. I had an installation there which resulted with periodic bosd when sata pt was used. +if I pass the /dev node, I don't get the errors but the performance is horrible due to high hdd usage +I've tested the same setup with ubuntu, doing read and write to the device of multiple GB (200GB~), no issue at all. +I've opened an issue at virtio-win and it was closed claiming it is a sata pt issue after trying latest virtio-win. +Steps to reproduce: +1. define a sata virtio controller +2. pass a physical sata drive to the guest attached to the sata controller define in step 1 +3. define a windows iso as cdrom +4. try to install windows on the device +Additional information: +[save.xml.txt](/uploads/0b7eb56d5fe00ff11341483d3d47ebed/save.xml.txt) +[qemu.cmd.txt](/uploads/b948eee1a95321d11136b96352caace0/qemu.cmd.txt) diff --git a/results/classifier/118/graphic/1990 b/results/classifier/118/graphic/1990 new file mode 100644 index 000000000..96e65544b --- /dev/null +++ b/results/classifier/118/graphic/1990 @@ -0,0 +1,49 @@ +graphic: 0.964 +device: 0.893 +architecture: 0.819 +arm: 0.757 +semantic: 0.699 +debug: 0.689 +ppc: 0.679 +PID: 0.628 +performance: 0.615 +permissions: 0.600 +kernel: 0.596 +files: 0.589 +boot: 0.588 +register: 0.547 +vnc: 0.476 +socket: 0.469 +user-level: 0.445 +network: 0.442 +mistranslation: 0.392 +hypervisor: 0.323 +virtual: 0.236 +risc-v: 0.229 +TCG: 0.194 +peripherals: 0.191 +assembly: 0.174 +VMM: 0.157 +i386: 0.112 +x86: 0.102 +KVM: 0.027 + +qemu ASSERT [ArmCpuDxe] DefaultExceptionHandler.c:333 on Mac M3 +Description of problem: +I am installing Podman 4.7.2 and `podman-machine` uses `qemu-system-aarch64` to boot up an embedded coreos image to run containers. +With the new Apple M3 hardware, I am experiencing a QEMU assertion failure almost all of the time. + + + +`ASSERT [ArmCpuDxe] /home/kraxel/projects/qemu/roms/edk2/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(333): ((BOOLEAN)(0==1))` + +I have been unable to get the full crash output - I didn't figure out how to resize the console any larger, and I tried a couple different ways to hook the console up to qemu stdout without any success. (since the kernel command line parameters are not passed in, but instead the image uses a bootloader) + +I believe this is the same issue I experience, but with a better capture of the crash: +https://github.com/lima-vm/lima/issues/1996 +Steps to reproduce: +1. Use Mac M3 (Max in my case) +2. Install Podman +3. Run `podman-machine init` +4. Run `podman-machine start --log-level=debug` +5. Crash (almost certainly) diff --git a/results/classifier/118/graphic/1997 b/results/classifier/118/graphic/1997 new file mode 100644 index 000000000..113a461e1 --- /dev/null +++ b/results/classifier/118/graphic/1997 @@ -0,0 +1,50 @@ +graphic: 0.957 +architecture: 0.953 +arm: 0.917 +device: 0.815 +semantic: 0.773 +virtual: 0.733 +register: 0.710 +hypervisor: 0.690 +debug: 0.681 +vnc: 0.678 +VMM: 0.672 +files: 0.670 +kernel: 0.668 +socket: 0.665 +performance: 0.658 +mistranslation: 0.618 +PID: 0.607 +ppc: 0.593 +boot: 0.583 +permissions: 0.568 +risc-v: 0.553 +user-level: 0.533 +assembly: 0.501 +network: 0.461 +TCG: 0.388 +KVM: 0.144 +peripherals: 0.102 +i386: 0.096 +x86: 0.010 + +Disk corruption on ARM64 (Apple Silicon) Linux VMs +Description of problem: +aarch64 Linux VMs will encounter disk corruption if they're set up with a filesystem that will notice it when it happens, e.g. BTRFS. This seems to be across the board with products, including Apple Hypervisor Framework, or just QEMU, so it very well might be an aarch64 Linux bug. +Steps to reproduce: +1. Install an aarch64 Linux VM using BTRFS as the root filesystem. ZFS might recognize silent corruption readily as well. +2. Run `stress-ng --iomix 4` +3. Check your `dmesg` and/or `btrfs check --force <device>` to check for filesystem corruption. +Additional information: +This is discussed in two other tickets, but I'm hoping to get more attention to the problem here. +[https://github.com/lima-vm/lima/issues/1957](https://github.com/lima-vm/lima/issues/1957) +[](https://github.com/utmapp/UTM/issues/4840) + + + + + +I can't seem to figure out how to upload images, but you can probably get to the image that I'm trying to share somehow... + + +``` diff --git a/results/classifier/118/graphic/1998 b/results/classifier/118/graphic/1998 new file mode 100644 index 000000000..6b1276a1e --- /dev/null +++ b/results/classifier/118/graphic/1998 @@ -0,0 +1,57 @@ +graphic: 0.804 +architecture: 0.780 +kernel: 0.770 +device: 0.729 +vnc: 0.721 +PID: 0.694 +debug: 0.679 +ppc: 0.676 +performance: 0.661 +register: 0.597 +files: 0.593 +peripherals: 0.559 +hypervisor: 0.551 +VMM: 0.547 +permissions: 0.544 +virtual: 0.536 +x86: 0.506 +KVM: 0.502 +network: 0.500 +user-level: 0.488 +socket: 0.486 +i386: 0.483 +boot: 0.460 +semantic: 0.453 +risc-v: 0.428 +TCG: 0.410 +mistranslation: 0.366 +arm: 0.336 +assembly: 0.184 + +acpihp does not work with some common guest kernels +Description of problem: +for pc-q35 6.1, 7.2, any guest kernel with `ACPI: Core revision` < 20230331, can not hot plug the nvidia GPUs. +So basically only guest kernel >= 6.5 can make it work so far. +But majority of server kernels are still at 4.18, 5.x. I wonder if it possible to be fixed? +I also don't know is this qemu bug? bios bug? or actually ACPIA's bug? + +journal -k report error like following: +``` +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 0: no space for [mem size 0x01000000] +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 0: failed to assign [mem size 0x01000000] +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 6: assigned [mem 0x81800000-0x8187ffff pref] +Nov 11 17:53:00 VMTEST kernel: pci 0000:08:00.0: BAR 5: assigned [io 0xa000-0xa07f] +Nov 11 17:53:00 VMTEST kernel: nvidia 0000:08:00.0: enabling device (0000 -> 0003) +Nov 11 17:53:00 VMTEST kernel: NVRM: This PCI I/O region assigned to your NVIDIA device is invalid: + NVRM: BAR0 is 0M @ 0x0 (PCI:0000:08:00.0) +Nov 11 17:53:00 VMTEST kernel: nvidia: probe of 0000:08:00.0 failed with error -1 +``` +Steps to reproduce: +1. run the instance as I described above +2. in qemu monitor: device_add vfio-pci,host=0000:06:00.0,id=gpu0,bus=pci.8 +3. login to the vm console then nvidia-smi to see the failure + +workaround: +`ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off` to disable the acpihp then pciehp can make it work. +Additional information: + diff --git a/results/classifier/118/graphic/2006 b/results/classifier/118/graphic/2006 new file mode 100644 index 000000000..2b4d03464 --- /dev/null +++ b/results/classifier/118/graphic/2006 @@ -0,0 +1,72 @@ +graphic: 0.919 +hypervisor: 0.909 +peripherals: 0.884 +permissions: 0.873 +semantic: 0.853 +socket: 0.844 +device: 0.838 +KVM: 0.833 +mistranslation: 0.831 +register: 0.831 +virtual: 0.830 +assembly: 0.828 +debug: 0.826 +architecture: 0.824 +performance: 0.820 +VMM: 0.809 +TCG: 0.789 +PID: 0.789 +risc-v: 0.779 +ppc: 0.762 +boot: 0.757 +arm: 0.750 +user-level: 0.746 +x86: 0.740 +i386: 0.740 +kernel: 0.707 +files: 0.699 +vnc: 0.688 +network: 0.635 + +migrating failed with rcu_preempt message on proxmox 8 +Description of problem: +when i migrate the VM from one host to another, it fails and give messages: + + ``` +[ 584.109502] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: +[ 584.109534] rcu: 1-...!: (0 ticks this GP) idle=1408/0/0x0 softirq=8428/8428 fqs=0 (false positive?) +[ 584.109556] (detected by 0, t=5252 jiffies, g=2953, q=74 ncpus=2) +[ 584.109561] Sending NMI from CPU 0 to CPUs 1: +[ 584.109587] NMI backtrace for cpu 1 skipped: idling at native_safe_halt+0xb/0x10 +[ 584.110564] rcu: rcu_preempt kthread timer wakeup didn't happen for 5251 jiffies! g2953 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 +[ 584.110585] rcu: Possible timer handling issue on cpu=1 timer-softirq=8006 +[ 584.110597] rcu: rcu_preempt kthread starved for 5252 jiffies! g2953 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=1 +[ 584.110614] rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. +[ 584.110645] rcu: RCU grace-period kthread stack dump: +[ 584.110658] task:rcu_preempt state:I stack:0 pid:15 ppid:2 flags:0x00004000 +[ 584.110667] Call Trace: +[ 584.110672] <TASK> +[ 584.110688] __schedule+0x351/0xa20 +[ 584.110699] ? rcu_gp_cleanup+0x480/0x480 +[ 584.110704] schedule+0x5d/0xe0 +[ 584.110705] schedule_timeout+0x94/0x150 +[ 584.110709] ? __bpf_trace_tick_stop+0x10/0x10 +[ 584.110714] rcu_gp_fqs_loop+0x141/0x4c0 +[ 584.110717] rcu_gp_kthread+0xd0/0x190 +[ 584.110720] kthread+0xe9/0x110 +[ 584.110725] ? kthread_complete_and_exit+0x20/0x20 +[ 584.110728] ret_from_fork+0x22/0x30 +[ 584.110735] </TASK> +[ 584.110736] rcu: Stack dump where RCU GP kthread last ran: +[ 584.110747] Sending NMI from CPU 0 to CPUs 1: +[ 584.110757] NMI backtrace for cpu 1 skipped: idling at native_safe_halt+0xb/0x10 + + ``` + +we can reproduce on our R630 cluster easily, but it is OK on R730 cluster and R740 cluster. +Steps to reproduce: +1. create and run an VM +2. migrate the vm to other host +3. it failed with message +Additional information: +i downgrade the pve-qemu-kvm from 8.1.2-4 to 8.0.2-3, same problem. diff --git a/results/classifier/118/graphic/2012 b/results/classifier/118/graphic/2012 new file mode 100644 index 000000000..62598835e --- /dev/null +++ b/results/classifier/118/graphic/2012 @@ -0,0 +1,42 @@ +graphic: 0.880 +device: 0.878 +boot: 0.862 +PID: 0.746 +debug: 0.697 +architecture: 0.694 +socket: 0.659 +files: 0.591 +semantic: 0.590 +TCG: 0.580 +vnc: 0.574 +risc-v: 0.564 +performance: 0.557 +permissions: 0.550 +ppc: 0.537 +kernel: 0.508 +arm: 0.477 +network: 0.472 +register: 0.447 +VMM: 0.435 +mistranslation: 0.430 +user-level: 0.369 +KVM: 0.355 +hypervisor: 0.348 +peripherals: 0.222 +x86: 0.185 +virtual: 0.181 +assembly: 0.140 +i386: 0.131 + +Possible regression: Windows 95 setup fails on show of license +Description of problem: +Install of Windows 95 fails when showing the license. Qemu v8.1.0 is fine, Qemu 8.1.3 and later failes. Git bisect suggest the problem may have been introduced at 9fb45b05582438dcd52d2d48d48feb05de680c37 +Steps to reproduce: +1. Find install CD for Windows 95 and a DOS boot floppy +2. Create a harddrive (size 300MB) +3. Boot from floppy, create and format partition C: using all available space +4. change to the CD at D: and run command SETUP.EXE +5. follow instructions until display of license +6. See error: SUWIN caused a General Protection Fault in module <unknown> +Additional information: + diff --git a/results/classifier/118/graphic/2015 b/results/classifier/118/graphic/2015 new file mode 100644 index 000000000..9c0fcf3e4 --- /dev/null +++ b/results/classifier/118/graphic/2015 @@ -0,0 +1,57 @@ +graphic: 0.932 +boot: 0.929 +device: 0.860 +ppc: 0.806 +vnc: 0.752 +files: 0.737 +architecture: 0.731 +performance: 0.675 +permissions: 0.619 +semantic: 0.616 +hypervisor: 0.596 +network: 0.548 +PID: 0.547 +kernel: 0.546 +peripherals: 0.534 +socket: 0.489 +register: 0.446 +x86: 0.442 +debug: 0.427 +risc-v: 0.363 +TCG: 0.341 +assembly: 0.313 +mistranslation: 0.299 +VMM: 0.255 +arm: 0.249 +i386: 0.219 +user-level: 0.191 +virtual: 0.183 +KVM: 0.097 + +qemu-system-sparc fails to boot Solaris 8 in an emulated SS-5 +Description of problem: +Sun PROM fails to boot Solaris 8 in an emulated Sparcstation 5, with qemu exiting with a `trap 0x29` error. +Steps to reproduce: +1. Launch qemu with command line above +2. Sun PROM tries to boot from the network and shows `Tiemout waiting for ARP/RARP packet` messages +3. Interrupt network boot entering `sendkey stop-a` in qemu monitor (`compat_monitor0`) +4. Back in Sun PROM, boot from cdrom: `boot cdrom:d` +5. Solaris 8 starts booting +6. qemu exits with fatal error + +```plaintext +qemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled, Error state +pc: f0041298 npc: f004129c +%g0-7: 00000000 f02441a8 04400fc2 000001e2 00000027 f0243b88 00000000 f0244020 +%o0-7: ffff8000 00008000 00000f00 044000c1 f0258518 ffeec000 fbe3a4b8 f0041be4 +%l0-7: 04400fc1 f0041c78 f0041c7c 00000002 0000010f 00000002 0000002a fbe39f78 +%i0-7: ffff8000 00008000 00000f00 044000c2 00000000 ffeec000 fbe3a020 f0041be4 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +psr: 04000fc1 (icc: ---- SPE: SP-) wim: 00000002 +fsr: 00000000 y: 00000000 +``` +Additional information: + diff --git a/results/classifier/118/graphic/2022 b/results/classifier/118/graphic/2022 new file mode 100644 index 000000000..ccb1ac62b --- /dev/null +++ b/results/classifier/118/graphic/2022 @@ -0,0 +1,41 @@ +graphic: 0.890 +device: 0.612 +debug: 0.579 +semantic: 0.545 +network: 0.503 +socket: 0.450 +vnc: 0.395 +performance: 0.369 +boot: 0.356 +architecture: 0.338 +peripherals: 0.315 +risc-v: 0.304 +ppc: 0.303 +register: 0.276 +files: 0.258 +PID: 0.252 +arm: 0.201 +permissions: 0.198 +kernel: 0.196 +VMM: 0.190 +TCG: 0.180 +virtual: 0.176 +user-level: 0.172 +mistranslation: 0.152 +x86: 0.122 +i386: 0.111 +hypervisor: 0.079 +assembly: 0.032 +KVM: 0.016 + +Win32s crashes qemu (regression, bisected) +Description of problem: +Whenever I start a Win32s application (FREECELL.EXE), qemu says "qemu: Bad ram pointer 0x7f4b13a80000" and aborts. I tried a few different versions of Win32s (I specifically remember 1.15a and 1.25a), but it does not seem to matter. I am using only the standard VGA driver and nothing else that would not be present in a standard install of the guest components. +Steps to reproduce: +1. Run any Win32s application +2. +3. +Additional information: +It worked fine before this commit, both on stable-8.1 as well as the master branch: + +4f8f41272e accel: Replace target_ulong with vaddr in probe_*() diff --git a/results/classifier/118/graphic/2025 b/results/classifier/118/graphic/2025 new file mode 100644 index 000000000..b3d4bc0e8 --- /dev/null +++ b/results/classifier/118/graphic/2025 @@ -0,0 +1,56 @@ +graphic: 0.980 +device: 0.939 +peripherals: 0.890 +virtual: 0.878 +performance: 0.682 +PID: 0.543 +VMM: 0.542 +mistranslation: 0.542 +ppc: 0.533 +semantic: 0.508 +vnc: 0.494 +debug: 0.428 +socket: 0.369 +files: 0.365 +register: 0.359 +arm: 0.354 +permissions: 0.352 +risc-v: 0.337 +architecture: 0.320 +boot: 0.265 +TCG: 0.250 +user-level: 0.243 +kernel: 0.212 +assembly: 0.157 +i386: 0.140 +hypervisor: 0.107 +x86: 0.089 +network: 0.061 +KVM: 0.018 + +Can't make the touchscreen work in Windows VM, device virtio-multitouch-pci not starting +Description of problem: +I tried the multitouch on qemu 8, by adding "-device virtio-multitouch-pci" to the qemu cmd line +I could make the multitouch work for an Ubuntu VM, but not for a Windows VM +Last version of Virtio drivers are installed in Windows. + +Here are the issues i can see in windows : + + +Windows Events of virtio input driver device : + +``` +Device PCI\VEN_1AF4&DEV_1052&SUBSYS_11001AF4&REV_01\3&2411e6fe&0&18 had a problem starting. +Driver Name: oem7.inf +Class Guid: {745a17a0-74d3-11d0-b6fe-00a0c90f57da} +Service: VirtioInput +Lower Filters: +Upper Filters: +Problem: 0xA +Problem Status: 0xC000009A +``` +Qemu didnt produce any logs regarding this PCI + +Do I miss something ? + +Thanks for your help diff --git a/results/classifier/118/graphic/2038 b/results/classifier/118/graphic/2038 new file mode 100644 index 000000000..672c37bbf --- /dev/null +++ b/results/classifier/118/graphic/2038 @@ -0,0 +1,46 @@ +graphic: 0.953 +device: 0.829 +PID: 0.825 +ppc: 0.814 +files: 0.641 +debug: 0.616 +vnc: 0.607 +semantic: 0.580 +performance: 0.553 +TCG: 0.527 +arm: 0.511 +network: 0.506 +architecture: 0.498 +register: 0.444 +peripherals: 0.443 +user-level: 0.420 +i386: 0.404 +risc-v: 0.370 +socket: 0.359 +VMM: 0.319 +hypervisor: 0.303 +x86: 0.297 +mistranslation: 0.255 +kernel: 0.255 +permissions: 0.250 +boot: 0.239 +KVM: 0.223 +virtual: 0.163 +assembly: 0.029 + +simpletrace.py does nothing, and syntax error when called from bash script +Description of problem: +The simpletrace python script appears to do nothing when I run it as above. + +It appears to run (but do nothing) when called from my terminal but there is also a syntax error when I run it from the bash script above. + +``` +SyntaxError: invalid syntax + File "<fstring>", line 1 + (pid=) + ^ +``` + +I think this syntax error is caused by the line `print(f'{event.name} {delta_ns / 1000:0.3f} {pid=} ' + ' '.join(fields))` +Additional information: + diff --git a/results/classifier/118/graphic/2042 b/results/classifier/118/graphic/2042 new file mode 100644 index 000000000..ca0c0fb96 --- /dev/null +++ b/results/classifier/118/graphic/2042 @@ -0,0 +1,48 @@ +graphic: 0.971 +device: 0.867 +semantic: 0.819 +performance: 0.753 +hypervisor: 0.748 +x86: 0.685 +debug: 0.637 +boot: 0.632 +virtual: 0.502 +user-level: 0.476 +PID: 0.433 +socket: 0.396 +architecture: 0.395 +register: 0.379 +risc-v: 0.367 +i386: 0.339 +mistranslation: 0.327 +ppc: 0.325 +vnc: 0.324 +kernel: 0.287 +VMM: 0.263 +network: 0.257 +permissions: 0.254 +TCG: 0.189 +assembly: 0.174 +arm: 0.170 +files: 0.154 +peripherals: 0.140 +KVM: 0.016 + +Not able to reboot Linux guest on Windows host +Description of problem: +I am running Linux Mint on Windows, but when I try to reboot the machine, I get the following error: + +qemu: WHPX: Unexpected VP exit code 4 + +I did some experiments changing the flags I use when I launch Qemu and I realized that if I set -smp 1 it does not fail. Furthermore, if I set the irqchip to off (kernel-irqchip=off) it does not fail either, but both options do not have good performance at all. I realized too that if I set 4 cores (-smp 4), the error might appear up to 4 times. + +What seems to be failing then is the APIC emulation that Hyper-V provides. Does anyone know if: + +1. Am I missing a flag when launching Qemu? +2. Is it there a patch to solve this? + +Any leads for solving this problem would be highly appreciated. +Steps to reproduce: +1. Install MSYS +2. Open MSYS and run pacman -S mingw-w64-x86_64-qemu +3. Launch Qemu and reboot machine diff --git a/results/classifier/118/graphic/2050 b/results/classifier/118/graphic/2050 new file mode 100644 index 000000000..a200abc73 --- /dev/null +++ b/results/classifier/118/graphic/2050 @@ -0,0 +1,37 @@ +graphic: 1.000 +architecture: 0.995 +boot: 0.978 +device: 0.893 +performance: 0.465 +files: 0.307 +register: 0.199 +semantic: 0.197 +arm: 0.180 +vnc: 0.146 +ppc: 0.112 +permissions: 0.109 +user-level: 0.098 +socket: 0.093 +debug: 0.089 +PID: 0.080 +mistranslation: 0.061 +risc-v: 0.032 +virtual: 0.030 +TCG: 0.024 +network: 0.015 +VMM: 0.014 +peripherals: 0.012 +kernel: 0.006 +hypervisor: 0.005 +assembly: 0.002 +KVM: 0.001 +x86: 0.001 +i386: 0.000 + +Graphical glitch on boot screen of ubuntu aarch64 +Description of problem: +Glitches on boot screen. +Additional information: + + +(The "TIANO Core" screen before this has similar issues) diff --git a/results/classifier/118/graphic/2056 b/results/classifier/118/graphic/2056 new file mode 100644 index 000000000..00245bb97 --- /dev/null +++ b/results/classifier/118/graphic/2056 @@ -0,0 +1,44 @@ +graphic: 0.964 +device: 0.920 +ppc: 0.858 +vnc: 0.764 +PID: 0.758 +virtual: 0.691 +files: 0.655 +register: 0.651 +architecture: 0.646 +socket: 0.632 +peripherals: 0.632 +performance: 0.604 +permissions: 0.544 +semantic: 0.518 +risc-v: 0.499 +boot: 0.496 +arm: 0.453 +VMM: 0.448 +mistranslation: 0.418 +hypervisor: 0.410 +TCG: 0.409 +assembly: 0.400 +kernel: 0.390 +network: 0.380 +debug: 0.298 +user-level: 0.209 +KVM: 0.179 +i386: 0.117 +x86: 0.066 + +macOS Cocoa title bar covers top of VM screen +Description of problem: +When using the Cocoa interface the title bar covers the top part of the VM screen. In Windows XP, using show-cursor=on and USB tablet (-usb -device usb-tablet,bus=usb-bus.0), the mouse cursor seems to be off by the height of the title bar; to click on a target the mouse cursor has to be below the target by about the height of the top bar. +Steps to reproduce: +1. Run Qemu using the Cocoa-interface (-display cocoa) +Additional information: +The problem exists in both Qemu 8.2.0 (compiled from source) as well as in the MacPorts version (version 8.0.5). Further testing shows the same problem in versions 6.2.0, 7.0.0, and 7.1.0. This problem did not exist in previous versions of macOS. + +A screenshot is enclosed: + + +For similar reports, see: https://www.emaculation.com/forum/viewtopic.php?p=77350#p77350 and https://github.com/phil-opp/blog_os/issues/1249#issuecomment-1825933581 and https://68kmla.org/bb/index.php?threads/a-self-contained-qemu-based-a-ux-system-for-macos.45106/post-504970 + +The problem exists on both Apple Silicon and Intel hardware. diff --git a/results/classifier/118/graphic/2057 b/results/classifier/118/graphic/2057 new file mode 100644 index 000000000..50f81fc91 --- /dev/null +++ b/results/classifier/118/graphic/2057 @@ -0,0 +1,35 @@ +graphic: 0.926 +device: 0.845 +network: 0.581 +socket: 0.422 +mistranslation: 0.411 +debug: 0.354 +semantic: 0.324 +performance: 0.268 +architecture: 0.256 +vnc: 0.220 +hypervisor: 0.217 +files: 0.200 +arm: 0.179 +peripherals: 0.177 +permissions: 0.171 +PID: 0.164 +register: 0.152 +TCG: 0.142 +boot: 0.121 +VMM: 0.109 +risc-v: 0.103 +i386: 0.101 +kernel: 0.067 +virtual: 0.066 +user-level: 0.064 +x86: 0.061 +ppc: 0.033 +assembly: 0.026 +KVM: 0.004 + +QEMU 8.2 configure error +Description of problem: +please see output upper +Steps to reproduce: +1. Just run ./configure diff --git a/results/classifier/118/graphic/2059 b/results/classifier/118/graphic/2059 new file mode 100644 index 000000000..17ceceba6 --- /dev/null +++ b/results/classifier/118/graphic/2059 @@ -0,0 +1,53 @@ +graphic: 0.838 +kernel: 0.809 +architecture: 0.727 +device: 0.655 +debug: 0.615 +semantic: 0.608 +ppc: 0.558 +files: 0.556 +performance: 0.535 +PID: 0.508 +hypervisor: 0.480 +vnc: 0.455 +virtual: 0.383 +socket: 0.377 +permissions: 0.371 +x86: 0.364 +user-level: 0.332 +risc-v: 0.332 +TCG: 0.324 +arm: 0.312 +boot: 0.307 +register: 0.299 +peripherals: 0.297 +network: 0.289 +mistranslation: 0.276 +VMM: 0.272 +i386: 0.249 +KVM: 0.203 +assembly: 0.189 + +Solaris 2.6.5 panic when trying to debug a binary with Sun Workshop V5n1, or V6n1 debugger +Description of problem: +Following [this guide](https://www.gekk.info/articles/solaris26.htm), and similarly to issue #1166, the guest panics when one tries to debug a binary with the debugger provided in [Sun Workshop V5n1](https://archive.org/details/sunworkshopforsolaris2vol5num1_704546810revb), and in [Sun Workshop v6n1](https://archive.org/details/devpro_v6n1) as well. +The Sun Workshop is EOL, available at the archive, with free non-expiring demo licenses [made available](https://archive.org/details/suncomp-lic) by Sun before the Oracle acquisition. +The guest was patched with the latest available patches included [in this cluster](https://archive.org/details/sun26gnu). +The following information was collected when debugging bunzip2, but any binary panics the guest. +``` +panic: Non-parity synchronous error: ctx=54 va=ef7cbc44 pa=e0a8c44 +syncing filesystems... 15 done +NOTICE: zs3:ring buffer overflow +``` +Steps to reproduce: +1. Start the Sun Workshop (SUNWspro/bin/workshop), go to the Debugger in the menu +2. Debug/New Program, load any binary, place a breakpoint in main or wherever +3. Execute, guest kernel panic +Additional information: +This happens with the Fujitsu MB86904 specified as CPU, and without specifying a cpu, using the default for the SS-5. + + + +Explicitly setting the TI MicroSparc I and setting memory to 32M seems to start the debugger, the guest still panics, but a bit further down the line + + diff --git a/results/classifier/118/graphic/2061 b/results/classifier/118/graphic/2061 new file mode 100644 index 000000000..e6a8dccb1 --- /dev/null +++ b/results/classifier/118/graphic/2061 @@ -0,0 +1,43 @@ +graphic: 0.957 +boot: 0.946 +device: 0.934 +performance: 0.845 +register: 0.820 +architecture: 0.807 +debug: 0.801 +PID: 0.794 +hypervisor: 0.789 +semantic: 0.734 +risc-v: 0.722 +socket: 0.718 +vnc: 0.680 +mistranslation: 0.631 +ppc: 0.630 +TCG: 0.597 +arm: 0.584 +files: 0.571 +virtual: 0.532 +kernel: 0.532 +VMM: 0.512 +permissions: 0.486 +network: 0.467 +user-level: 0.451 +peripherals: 0.395 +x86: 0.384 +KVM: 0.358 +i386: 0.357 +assembly: 0.348 + +Regression: QEMU 8.2.0 VFIO GPU guests cannot reboot due to improper reset +Description of problem: +Prior to QEMU 8.2.0 (i.e. 8.1.4), rebooting the guest with VFIO GPU passed through would result in a proper reboot. +After updating to QEMU 8.2.0, rebooting the guest results in a black screen due to improper reset behaviour. +I was able to narrow this down to commit #3d779ab. Compiling and running with commit #0bddd88 results in the correct behaviour. +That is, the GPU properly resets on guest reboot and boots successfully to Windows. +Steps to reproduce: +1. Update to QEMU 8.2.0 +2. Boot Windows 11 23H2 +3. Reboot +4. Notice a black screen +Additional information: + diff --git a/results/classifier/118/graphic/2073 b/results/classifier/118/graphic/2073 new file mode 100644 index 000000000..c71b0f7ab --- /dev/null +++ b/results/classifier/118/graphic/2073 @@ -0,0 +1,46 @@ +graphic: 0.885 +permissions: 0.821 +device: 0.809 +semantic: 0.544 +register: 0.522 +performance: 0.459 +kernel: 0.423 +mistranslation: 0.423 +PID: 0.393 +ppc: 0.387 +vnc: 0.381 +arm: 0.357 +VMM: 0.335 +user-level: 0.329 +boot: 0.323 +x86: 0.299 +i386: 0.296 +architecture: 0.277 +socket: 0.268 +KVM: 0.266 +risc-v: 0.266 +debug: 0.246 +network: 0.237 +TCG: 0.188 +virtual: 0.188 +peripherals: 0.172 +assembly: 0.168 +hypervisor: 0.124 +files: 0.100 + +Audio: missing ability to disable microphone input from host? +Description of problem: +**It appears there is no way to disable the microphone / input to the audio backend device(s).** + + +There are at least two cases where this matters: +1. The host has no microphone input (e.g. only HDMI audio output with video). +2. The host has a microphone input, but the user doesn't want the guest VM to have access to the microphone/input. + +I tried the option in.channels=0, as that seemed the most obvious way, though that doesn't work. + +For -audio dsound, it appears that CLSID_DirectSoundCapture is unconditionally acquired. + +There will also be later periodic warning/text outputs from QEMU "Could not create a backend for voice virtio.in", if you're running on a host system with no audio input device. + +Adding a couple backend checks for channels > 0 may work well. Not sure if it matters that audio front end device in the VM still thinks there is an audio input. diff --git a/results/classifier/118/graphic/2075 b/results/classifier/118/graphic/2075 new file mode 100644 index 000000000..d6dbc8054 --- /dev/null +++ b/results/classifier/118/graphic/2075 @@ -0,0 +1,40 @@ +graphic: 0.954 +device: 0.871 +vnc: 0.824 +ppc: 0.800 +socket: 0.713 +PID: 0.694 +network: 0.661 +semantic: 0.647 +performance: 0.586 +permissions: 0.562 +register: 0.536 +arm: 0.514 +boot: 0.506 +architecture: 0.471 +files: 0.446 +risc-v: 0.434 +VMM: 0.422 +debug: 0.416 +hypervisor: 0.383 +mistranslation: 0.363 +kernel: 0.359 +virtual: 0.354 +TCG: 0.321 +user-level: 0.275 +assembly: 0.234 +i386: 0.185 +peripherals: 0.156 +x86: 0.136 +KVM: 0.063 + +QGA guest-get-fsinfo can not return windows dynamic volumes +Description of problem: +Install qemu-ga (newest version) in Windows, create multiple dynamic volumes（containing multiple disks）, + + +get them information via guest-get-fsinfo, but guest-get-fsinfo does not return the the dynamic volume. +Steps to reproduce: +virsh qemu-agent-command {domain} --pretty '{ "execute": "guest-get-fsinfo" }' +Additional information: +Please see if this bug can be fixed by [qga-win: Fix guest-get-fsinfo multi-disks collection](https://patchew.org/QEMU/20231227071540.4035803-1-peng.ji@smartx.com/) diff --git a/results/classifier/118/graphic/2078 b/results/classifier/118/graphic/2078 new file mode 100644 index 000000000..6ca6c252f --- /dev/null +++ b/results/classifier/118/graphic/2078 @@ -0,0 +1,64 @@ +graphic: 0.916 +device: 0.821 +semantic: 0.803 +performance: 0.771 +virtual: 0.732 +user-level: 0.718 +debug: 0.697 +PID: 0.673 +network: 0.666 +architecture: 0.661 +arm: 0.648 +kernel: 0.590 +vnc: 0.573 +assembly: 0.547 +permissions: 0.497 +socket: 0.482 +hypervisor: 0.476 +ppc: 0.474 +files: 0.434 +risc-v: 0.418 +peripherals: 0.400 +register: 0.393 +boot: 0.371 +VMM: 0.368 +TCG: 0.339 +mistranslation: 0.312 +x86: 0.242 +i386: 0.170 +KVM: 0.081 + +Qemu crashes with SIGFPE on certain trapping arithmetic operations on m68k target +Description of problem: +I recently ported NetBSD to the Qemu m68k "virt" platform, and this was discovered when running NetBSD's automated tests. Certain arithmetic operation that will trap in the guest will crash Qemu. First case encountered is below. +Steps to reproduce: +1. Compile and run the following program in the m68k guest: + +``` +virt68k:thorpej 3$ cat crash-qemu.c +#include <limits.h> +#include <stdlib.h> + +int divisor = -1; + +int +main(int argc, char *argv[]) +{ + + if (argc > 1) + divisor = atoi(argv[1]); + + return INT_MIN / divisor; +} +virt68k:thorpej 4$ +``` + +Another minimal case would be: + +``` +move.l #-2147483648,%d0 +move.l #-1,%d1 +divsl.l %d1,%d1:%d0 +``` +Additional information: + diff --git a/results/classifier/118/graphic/2085 b/results/classifier/118/graphic/2085 new file mode 100644 index 000000000..ea1962a98 --- /dev/null +++ b/results/classifier/118/graphic/2085 @@ -0,0 +1,52 @@ +graphic: 0.989 +network: 0.900 +performance: 0.856 +virtual: 0.828 +debug: 0.828 +boot: 0.809 +device: 0.805 +architecture: 0.751 +permissions: 0.736 +arm: 0.734 +socket: 0.664 +semantic: 0.609 +PID: 0.594 +vnc: 0.560 +kernel: 0.516 +register: 0.515 +files: 0.470 +risc-v: 0.468 +TCG: 0.459 +VMM: 0.456 +peripherals: 0.421 +ppc: 0.397 +hypervisor: 0.389 +user-level: 0.299 +mistranslation: 0.288 +i386: 0.287 +assembly: 0.263 +x86: 0.252 +KVM: 0.246 + +screen doesn't update fully wth spice + virtio-vga graphics +Description of problem: +When using spice graphics with virtio-vga, display updates and missing and/or delayed making interaction unusable +Steps to reproduce: +Create a VM with spice graphics and virtio-vga with earlier mentioned command line + +Open ``remote-viewer spice://localhost:5900`` + +Boot the Fedora 39 server network installer CDROM ISO + +When Ananconda starts, select 'continue' at the first language choice screen + +Select 'Root Account' config option + +Toggle between "Disable root account" and "Enable root account" options + +Observe when the password entry box is shown/hidden, the screen does not redraw correctly +Additional information: +See also + +https://bugzilla.redhat.com/show_bug.cgi?id=2256884 +https://bbs.archlinux.org/viewtopic.php?id=291606 diff --git a/results/classifier/118/graphic/2090 b/results/classifier/118/graphic/2090 new file mode 100644 index 000000000..29b9c359a --- /dev/null +++ b/results/classifier/118/graphic/2090 @@ -0,0 +1,37 @@ +graphic: 0.943 +virtual: 0.921 +VMM: 0.907 +semantic: 0.837 +performance: 0.821 +device: 0.790 +vnc: 0.679 +files: 0.657 +user-level: 0.644 +boot: 0.639 +hypervisor: 0.629 +debug: 0.576 +kernel: 0.564 +risc-v: 0.546 +mistranslation: 0.526 +architecture: 0.468 +register: 0.454 +permissions: 0.450 +TCG: 0.439 +socket: 0.438 +network: 0.426 +i386: 0.426 +x86: 0.379 +KVM: 0.367 +PID: 0.349 +ppc: 0.292 +arm: 0.270 +peripherals: 0.233 +assembly: 0.157 + +Long initialisation of VM before boot. +Description of problem: +When i start VM in "Virtual machine manager" I got black screen, which hang there approximately one minute. After this delay VM begin booted and all work properly. Some time ago VMs booted immediately without mentioned delay after starting of VM. I checked all relevant log files, changed 3 times kernel, rebuilded Qemu, but problem persist. I don't know when problem began. + + + +## diff --git a/results/classifier/118/graphic/2094 b/results/classifier/118/graphic/2094 new file mode 100644 index 000000000..a90598c7a --- /dev/null +++ b/results/classifier/118/graphic/2094 @@ -0,0 +1,37 @@ +graphic: 0.841 +performance: 0.488 +mistranslation: 0.445 +device: 0.428 +semantic: 0.422 +network: 0.237 +arm: 0.160 +risc-v: 0.118 +x86: 0.109 +ppc: 0.105 +socket: 0.103 +register: 0.098 +assembly: 0.096 +architecture: 0.067 +user-level: 0.067 +boot: 0.059 +i386: 0.054 +peripherals: 0.054 +PID: 0.053 +vnc: 0.050 +kernel: 0.047 +virtual: 0.047 +files: 0.044 +debug: 0.043 +permissions: 0.039 +TCG: 0.037 +hypervisor: 0.036 +VMM: 0.036 +KVM: 0.021 + +Various record/replay avocado tests hang when run under gitlab CI +Description of problem: +While previous fixes have gone in including #2010 and #2013 we are still seeing +hangs on CI. Some examples: + + https://gitlab.com/thuth/qemu/-/jobs/5910241580#L227 + https://gitlab.com/thuth/qemu/-/jobs/5910241593#L396 diff --git a/results/classifier/118/graphic/2099 b/results/classifier/118/graphic/2099 new file mode 100644 index 000000000..1c25c25ed --- /dev/null +++ b/results/classifier/118/graphic/2099 @@ -0,0 +1,41 @@ +graphic: 0.971 +device: 0.799 +mistranslation: 0.628 +boot: 0.515 +semantic: 0.486 +performance: 0.462 +PID: 0.321 +debug: 0.314 +risc-v: 0.310 +socket: 0.300 +user-level: 0.291 +vnc: 0.283 +register: 0.277 +assembly: 0.258 +ppc: 0.248 +i386: 0.239 +arm: 0.222 +TCG: 0.198 +x86: 0.187 +architecture: 0.141 +VMM: 0.073 +kernel: 0.047 +virtual: 0.044 +hypervisor: 0.035 +network: 0.025 +peripherals: 0.024 +permissions: 0.023 +files: 0.022 +KVM: 0.011 + +Setting for initial GTK window size? +Description of problem: + +Steps to reproduce: +1. When starting QEMU on Windows, the GTK window size appears to be sized to approx 640x480, which is very hard to see on a 4k+ monitor. So interacting with the boot, reading BIOS messages, etc, isn't great. +2. It would be great to be able to specify the dimensions of the GTK window, say 2560x1600, and then just set "Zoom to Fit". +3. This way, the visible window area remains constant, and all stages of graphical interaction get scaled to a workable size. +4. The OS can be configured to say 2560x1600 once setup. +5. Perhaps I've overlook settings to accomplish this? + +Thank you. diff --git a/results/classifier/118/graphic/2100 b/results/classifier/118/graphic/2100 new file mode 100644 index 000000000..78825d058 --- /dev/null +++ b/results/classifier/118/graphic/2100 @@ -0,0 +1,36 @@ +graphic: 0.875 +device: 0.855 +mistranslation: 0.651 +socket: 0.613 +network: 0.567 +vnc: 0.551 +PID: 0.519 +architecture: 0.491 +files: 0.483 +semantic: 0.465 +ppc: 0.433 +performance: 0.431 +user-level: 0.418 +risc-v: 0.405 +TCG: 0.395 +arm: 0.384 +debug: 0.379 +register: 0.319 +i386: 0.286 +boot: 0.233 +VMM: 0.202 +permissions: 0.195 +x86: 0.175 +virtual: 0.165 +peripherals: 0.153 +hypervisor: 0.047 +assembly: 0.026 +KVM: 0.016 +kernel: 0.014 + +Add option to skip quit confirmation with Cocoa display +Additional information: +This change was originally requested in back in 2016, but got lost in the issue tracker migration: https://bugs.launchpad.net/qemu/+bug/1556372 + +Patch in question: +https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg05031.html diff --git a/results/classifier/118/graphic/2101 b/results/classifier/118/graphic/2101 new file mode 100644 index 000000000..3612d66f5 --- /dev/null +++ b/results/classifier/118/graphic/2101 @@ -0,0 +1,47 @@ +graphic: 0.957 +x86: 0.950 +user-level: 0.945 +architecture: 0.897 +TCG: 0.859 +device: 0.812 +files: 0.752 +performance: 0.712 +semantic: 0.681 +PID: 0.653 +VMM: 0.556 +socket: 0.510 +ppc: 0.504 +mistranslation: 0.503 +network: 0.496 +debug: 0.400 +kernel: 0.388 +vnc: 0.383 +permissions: 0.330 +peripherals: 0.327 +hypervisor: 0.322 +risc-v: 0.264 +KVM: 0.235 +boot: 0.190 +virtual: 0.180 +arm: 0.177 +register: 0.174 +assembly: 0.027 +i386: 0.016 + +[qemu-user/qemu-x86_64] run x86_64 'ls /' on aarch64 platform get wrong result +Description of problem: +``` + qemu-x86_64 -L /tmp/ls-x86_64/root-x86_64-ls /tmp/ls-x86_64/root-x86_64-ls/bin/ls -l / + ``` +get wrong result +Steps to reproduce: +1. copy /usr/bin/ls and the so library files it depends on from x86_64 platform to aarch64 platform +2. qemu-x86_64 -L /path/to/x86_64/lib/root/dir /path/to/ls / -l +Additional information: +Actual test script: +``` +# host +curl -Ls https://github.com/tcler/kiss-vm-ns/raw/master/utils/archive-ld-program.sh | sudo bash /dev/stdin ls +scp ls.x86_64.ash root@jiyin-fedora-39_aarch64: +ssh root@jiyin-fedora-39_aarch64 ./ls.x86_64.ash -l / +``` diff --git a/results/classifier/118/graphic/2116 b/results/classifier/118/graphic/2116 new file mode 100644 index 000000000..9b513f8f6 --- /dev/null +++ b/results/classifier/118/graphic/2116 @@ -0,0 +1,58 @@ +graphic: 0.990 +x86: 0.902 +user-level: 0.895 +performance: 0.875 +device: 0.861 +semantic: 0.836 +PID: 0.790 +peripherals: 0.781 +architecture: 0.744 +boot: 0.726 +debug: 0.697 +ppc: 0.658 +permissions: 0.650 +socket: 0.648 +kernel: 0.596 +network: 0.593 +files: 0.558 +vnc: 0.555 +i386: 0.543 +hypervisor: 0.511 +register: 0.483 +VMM: 0.462 +mistranslation: 0.449 +virtual: 0.446 +TCG: 0.381 +risc-v: 0.372 +arm: 0.323 +assembly: 0.235 +KVM: 0.130 + +[CRASH] OpenGL acceleration except gtk: bad interaction between NVIDIA usermode opengl libraries and QEMU seccomp -sandbox on,spawn=deny, crashes immediately on startup with Bad system call +Description of problem: +When running any of the above command lines, QEMU crashes with Bad system call (core dumped). Not exclusive to spice; it seems this is caused by QEMU forking during OpenGL initialization after seccomp takes effect. +Steps to reproduce: +1. Run the above commandline +2. Notice a Bad system call (core dumped) +Additional information: +This crash only happens if spawn=deny is set, resourcecontrol/obsolete/elevateprivileges don't cause crashes. + +The crash happens around the same time as an audit event is generated in dmesg: `audit: type=1326 audit(1705775880.776:14): auid=MYUSERID uid=MYUID gid=MYGID ses=REDACTED pid=REDACTED comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 arch=c000003e syscall=56 compat=0 ip=REDACTED code=REDACTED` + +`ausyscall c000003e 56` tells me it's `clone` which (iirc) is the syscall used by glibc to implement fork() (I might be wrong about glibc part) + +Suggested solution: move seccomp activation until just before guest code starts executing? make frontends (ie -display gtk/sdl/whatever, including -spice) initialize before seccomp? + +Workaround: `chmod -x /bin/nvidia-modprobe` if not using the NVIDIA gpu or use this wrapper script (untested, not enterprise-ready, I am not responsible if unexpected things happen): +- rename /bin/qemu-system-x86_64 to qemu-system-x86_64.real +- put this in /bin/qemu-system-x86_64 and chmod +x it +```sh +#!/usr/bin/env sh +chmod -x /bin/nvidia-modprobe +qemu-system-x86_64.real $@ & disown +sleep 10 # excessive but maybe safer? +chmod +x /bin/nvidia-modprobe +``` +Also, you can use -display gtk,gl=on instead, or (unknown security implications) remove spawn=deny from -sandbox args + +original bug report was https://gitlab.com/libvirt/libvirt/-/issues/585 but I realized this was more of a qemu issue than a libvirt one diff --git a/results/classifier/118/graphic/2136 b/results/classifier/118/graphic/2136 new file mode 100644 index 000000000..c45e4cf84 --- /dev/null +++ b/results/classifier/118/graphic/2136 @@ -0,0 +1,65 @@ +graphic: 0.926 +device: 0.926 +performance: 0.838 +architecture: 0.823 +semantic: 0.809 +user-level: 0.808 +PID: 0.790 +x86: 0.789 +network: 0.758 +vnc: 0.757 +risc-v: 0.681 +ppc: 0.676 +files: 0.660 +VMM: 0.646 +socket: 0.645 +kernel: 0.644 +arm: 0.641 +register: 0.637 +debug: 0.636 +permissions: 0.617 +boot: 0.608 +hypervisor: 0.588 +TCG: 0.577 +peripherals: 0.478 +mistranslation: 0.467 +virtual: 0.394 +assembly: 0.372 +KVM: 0.352 +i386: 0.322 + +on loongarch host, LSX vec get wrong result +Description of problem: +on loongarch host, the lsx insns get wrong result. +Steps to reproduce: +1. build linux-user on loongarch host with '--configure --target-list ='loongarch64-linux-user'' +2. build test code 'gcc --static test.c -o test' +3. run './build/qemu-loongarch64 test' +Additional information: +run 'qemu-loongarch64 test' +the result is + +`0: 2f2f2f2f +1: 0 +2: 2f2f2f2f +3: 0 +4: ffffffff +5: 0 +6: ffffffff +7: ffffffff` + +and the 6 or 7 may be ffffff or 0. + +run 'test' on loongarch host or run qemu-loongarch64 on x86_64 host. +the result is + +`0: 2f2f2f2f +1: 0 +2: 2f2f2f2f +3: 0 +4: 0 +5: 0 +6: 0 +7: 0` + +for more infomation see log.txt diff --git a/results/classifier/118/graphic/2138 b/results/classifier/118/graphic/2138 new file mode 100644 index 000000000..df0fc3860 --- /dev/null +++ b/results/classifier/118/graphic/2138 @@ -0,0 +1,52 @@ +graphic: 0.994 +device: 0.961 +ppc: 0.914 +PID: 0.872 +files: 0.840 +vnc: 0.826 +architecture: 0.807 +debug: 0.802 +semantic: 0.795 +register: 0.793 +TCG: 0.764 +arm: 0.752 +permissions: 0.701 +boot: 0.699 +VMM: 0.659 +performance: 0.652 +kernel: 0.626 +socket: 0.547 +network: 0.524 +risc-v: 0.472 +mistranslation: 0.379 +i386: 0.313 +user-level: 0.244 +hypervisor: 0.201 +x86: 0.167 +virtual: 0.141 +KVM: 0.114 +assembly: 0.080 +peripherals: 0.058 + +Build failure on macOS when using --disable-cocoa +Description of problem: +Build fails: + +``` +../qemu-8.2.1/meson.build:3741:13: ERROR: No host machine compiler for 'audio/coreaudio.m' +``` +Steps to reproduce: +1. On macOS run `./configure --disable-cocoa` + +Result: + +``` +Compiler for language objc skipped: feature cocoa disabled +``` +``` +../meson.build:3741:13: ERROR: No host machine compiler for 'audio/coreaudio.m' +``` +Additional information: +It seems your build script contains the assumption that an Objective-C compiler is not needed when the Cocoa UI is disabled, but it still appears to be needed to compile the CoreAudio code regardless of UI. + +This was originally reported to MacPorts here: https://trac.macports.org/ticket/67984 diff --git a/results/classifier/118/graphic/2139 b/results/classifier/118/graphic/2139 new file mode 100644 index 000000000..46aa665e2 --- /dev/null +++ b/results/classifier/118/graphic/2139 @@ -0,0 +1,39 @@ +graphic: 0.951 +device: 0.944 +boot: 0.944 +mistranslation: 0.837 +PID: 0.720 +debug: 0.718 +performance: 0.682 +files: 0.655 +architecture: 0.649 +socket: 0.645 +register: 0.625 +semantic: 0.595 +peripherals: 0.558 +assembly: 0.546 +permissions: 0.542 +risc-v: 0.521 +arm: 0.502 +user-level: 0.483 +network: 0.453 +vnc: 0.447 +ppc: 0.438 +TCG: 0.419 +VMM: 0.349 +kernel: 0.231 +i386: 0.188 +virtual: 0.162 +x86: 0.147 +hypervisor: 0.083 +KVM: 0.040 + +Super/Win key seems to release immediately on sdl+windows +Description of problem: +Currently on windows when trying SerenityOS the super key releases immediately so you can't use the shortcuts, with the GTK gui (gl off) it works though. but GTK has other problems with mouse which sometimes doesn't work at all, SDL seems to work well besides from this one issue. +Steps to reproduce: +1. Boot with default settings on wsl2 which launches qemu on windows if it's installed +2. Try to use any of the superkey shortcuts like superkey+space for a search popup https://github.com/SerenityOS/serenity/blob/dc47d01fdc62a1ee319310e2b11c26b8ebe8899d/Base/usr/share/man/man7/KeyboardShortcuts.md#L4 +3. Fail because it immediately opens the menu blocking the shortcuts. +Additional information: + diff --git a/results/classifier/118/graphic/2147 b/results/classifier/118/graphic/2147 new file mode 100644 index 000000000..087a577e8 --- /dev/null +++ b/results/classifier/118/graphic/2147 @@ -0,0 +1,39 @@ +graphic: 0.939 +device: 0.873 +semantic: 0.814 +debug: 0.767 +performance: 0.677 +architecture: 0.668 +vnc: 0.652 +register: 0.645 +PID: 0.615 +arm: 0.613 +network: 0.594 +ppc: 0.590 +risc-v: 0.569 +boot: 0.518 +socket: 0.507 +peripherals: 0.447 +mistranslation: 0.446 +VMM: 0.430 +TCG: 0.419 +user-level: 0.370 +kernel: 0.315 +hypervisor: 0.185 +files: 0.158 +i386: 0.146 +permissions: 0.143 +virtual: 0.115 +assembly: 0.091 +x86: 0.083 +KVM: 0.022 + +The Windows version of QEMU runs the semihost project without printing +Description of problem: +In Linux, running this command to execute the Semihost project will print `Hello World` in the console, but running in Windows will not print anything. + +I'd like to know if it's the windows version of qemu that doesn't have perfect support for semihost, or if I need to adjust the input parameters. +Steps to reproduce: + +Additional information: + diff --git a/results/classifier/118/graphic/2150 b/results/classifier/118/graphic/2150 new file mode 100644 index 000000000..68aae9eb4 --- /dev/null +++ b/results/classifier/118/graphic/2150 @@ -0,0 +1,43 @@ +TCG: 0.975 +graphic: 0.936 +arm: 0.927 +device: 0.924 +boot: 0.912 +performance: 0.810 +files: 0.655 +debug: 0.602 +network: 0.585 +ppc: 0.584 +PID: 0.578 +socket: 0.568 +kernel: 0.566 +architecture: 0.519 +semantic: 0.473 +mistranslation: 0.456 +vnc: 0.445 +register: 0.418 +risc-v: 0.331 +hypervisor: 0.316 +user-level: 0.266 +VMM: 0.176 +permissions: 0.170 +virtual: 0.160 +KVM: 0.158 +peripherals: 0.151 +assembly: 0.131 +x86: 0.120 +i386: 0.056 + +ERROR:tcg/optimize.c:580:do_constant_folding_2: code should not be reached +Description of problem: +After booting Windows 10 or 11 (ARM) QEMU suddenly quits with: + +ERROR:tcg/optimize.c:580:do_constant_folding_2: code should not be reached + +It seems like it is missing an OPCODE in that function? +Steps to reproduce: +1. Boot Windows +2. QEMU quits +3. +Additional information: + diff --git a/results/classifier/118/graphic/2154 b/results/classifier/118/graphic/2154 new file mode 100644 index 000000000..5dabfa3be --- /dev/null +++ b/results/classifier/118/graphic/2154 @@ -0,0 +1,37 @@ +register: 0.987 +mistranslation: 0.968 +graphic: 0.966 +architecture: 0.942 +device: 0.872 +socket: 0.780 +debug: 0.770 +network: 0.746 +arm: 0.728 +vnc: 0.685 +PID: 0.639 +semantic: 0.609 +performance: 0.604 +VMM: 0.569 +TCG: 0.500 +ppc: 0.469 +kernel: 0.444 +risc-v: 0.418 +x86: 0.409 +boot: 0.366 +assembly: 0.352 +user-level: 0.351 +i386: 0.308 +hypervisor: 0.305 +files: 0.241 +permissions: 0.231 +peripherals: 0.223 +virtual: 0.171 +KVM: 0.157 + +ID_AA64MMFR2_EL1 is all zeros +Description of problem: +When the `ID_AA64MMFR2_EL1` register is read via `mrs x[n], ID_AA64MMFR2_EL1`, it is read as all zeros. This is at the very least not correct for `ID_AA64MMFR2_EL1.ST`, which describes support for small translation tables (FEAT_TTST). +Steps to reproduce: +1. Run `mrs x[n], ID_AA64MMFR2_EL1` within qemu-system-aarch64 +Additional information: +FEAT_TTST is a relatively new aarch64 feature that appears to have caused many problems basically everywhere. However, [qemu has reportedly implemented it](https://www.qemu.org/2021/04/30/qemu-6-0-0/). diff --git a/results/classifier/118/graphic/2155 b/results/classifier/118/graphic/2155 new file mode 100644 index 000000000..c066e2d9b --- /dev/null +++ b/results/classifier/118/graphic/2155 @@ -0,0 +1,53 @@ +graphic: 0.958 +arm: 0.924 +architecture: 0.870 +semantic: 0.852 +device: 0.842 +ppc: 0.814 +performance: 0.784 +register: 0.750 +vnc: 0.702 +peripherals: 0.692 +files: 0.665 +x86: 0.537 +hypervisor: 0.520 +socket: 0.513 +PID: 0.508 +debug: 0.497 +virtual: 0.488 +TCG: 0.475 +VMM: 0.451 +assembly: 0.380 +network: 0.369 +risc-v: 0.368 +kernel: 0.358 +permissions: 0.349 +i386: 0.339 +boot: 0.272 +user-level: 0.266 +KVM: 0.167 +mistranslation: 0.142 + +LoadVM assert on ARM_FEATURE_M for Cortex M3 +Description of problem: +This appears to be a similar issue to https://gitlab.com/qemu-project/qemu/-/issues/1775 and https://gitlab.com/qemu-project/qemu/-/issues/1658 + +When running `loadvm` qemu aborts with this error: + +"qemu/target/arm/helper.c:12383: arm_security_space_below_el3: Assertion `!arm_feature(env, ARM_FEATURE_M)' failed." + +I've traced the error to `pmu_counter_enabled` in `qemu\target\arm\helper.c:1172` + [uint64_t mdcr_el2 = arm_mdcr_el2_eff(env)](https://gitlab.com/qemu-project/qemu/-/blob/v8.2.0/target/arm/helper.c?ref_type=tags#L1172) (link is to 8.2.0 release tag) + + +The issue is caused by attempting to get the MDCR_EL2 register prior to checking if the CPU has ARM_FEATURE_PMU support. + +A simple fix seems to be to check for `ARM_PMU_ENABLED` and returning early if it is not enabled. +Steps to reproduce: +1. Start emulation and connect monitor +2. savevm <snapshot-name> +3. Loadvm <snapshot-name> +Additional information: +See screenshot for stack trace + + diff --git a/results/classifier/118/graphic/2190 b/results/classifier/118/graphic/2190 new file mode 100644 index 000000000..0e423c212 --- /dev/null +++ b/results/classifier/118/graphic/2190 @@ -0,0 +1,37 @@ +graphic: 0.963 +mistranslation: 0.864 +device: 0.852 +semantic: 0.686 +performance: 0.657 +debug: 0.592 +network: 0.579 +files: 0.551 +architecture: 0.455 +user-level: 0.436 +PID: 0.430 +register: 0.423 +vnc: 0.397 +VMM: 0.390 +arm: 0.355 +boot: 0.330 +risc-v: 0.322 +hypervisor: 0.305 +i386: 0.298 +KVM: 0.297 +socket: 0.294 +x86: 0.288 +TCG: 0.285 +assembly: 0.279 +ppc: 0.264 +virtual: 0.262 +kernel: 0.200 +permissions: 0.138 +peripherals: 0.060 + +qemu-block-drivers.rst.inc is embedded twice +Description of problem: +`qemu-block-drivers.rst.inc` is included both in `docs/system/qemu-block-drivers.rst` and in `docs/system/images.rst`, so it is repeated both at https://www.qemu.org/docs/master/system/qemu-block-drivers.html and at https://www.qemu.org/docs/master/system/images.html . + +This also makes the generation of the sphinx `objects.inv` search index nondeterministic: it will point to one page or the other depending on random chance at build time. + +Perhaps instead of embedding the drivers, `images.rst` should point to https://www.qemu.org/docs/master/system/qemu-block-drivers.html for the list? diff --git a/results/classifier/118/graphic/2198 b/results/classifier/118/graphic/2198 new file mode 100644 index 000000000..15ab24141 --- /dev/null +++ b/results/classifier/118/graphic/2198 @@ -0,0 +1,55 @@ +graphic: 0.859 +permissions: 0.842 +boot: 0.817 +device: 0.801 +network: 0.799 +architecture: 0.788 +semantic: 0.762 +ppc: 0.662 +performance: 0.655 +mistranslation: 0.644 +register: 0.618 +socket: 0.613 +i386: 0.540 +vnc: 0.516 +debug: 0.487 +peripherals: 0.465 +kernel: 0.461 +KVM: 0.461 +PID: 0.450 +files: 0.418 +user-level: 0.394 +virtual: 0.387 +arm: 0.380 +hypervisor: 0.373 +risc-v: 0.372 +VMM: 0.286 +x86: 0.279 +TCG: 0.277 +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/118/graphic/2199 b/results/classifier/118/graphic/2199 new file mode 100644 index 000000000..e3f24584d --- /dev/null +++ b/results/classifier/118/graphic/2199 @@ -0,0 +1,42 @@ +graphic: 0.975 +device: 0.879 +peripherals: 0.829 +architecture: 0.782 +socket: 0.781 +files: 0.750 +boot: 0.727 +network: 0.700 +register: 0.681 +vnc: 0.653 +VMM: 0.648 +PID: 0.624 +kernel: 0.604 +hypervisor: 0.583 +performance: 0.557 +semantic: 0.554 +risc-v: 0.541 +permissions: 0.523 +debug: 0.511 +mistranslation: 0.508 +ppc: 0.489 +TCG: 0.465 +arm: 0.452 +user-level: 0.289 +x86: 0.259 +virtual: 0.258 +assembly: 0.199 +KVM: 0.177 +i386: 0.173 + +QEMU8 not working properly for Win9x guest +Description of problem: +Cannot boot to Win9x desktop. Enter safe mode of Win9x, then open C:\Windows\system\iosubsys, then rename drvwq117.vxd to drvwq117.vxd.bak, this problem solved.<br /> +Sound card and network card not found in Win9x Device Manager.<br /> +Cannot change resolution in Win9x Control Panel, this will cause "RUNDLL32 program error". + +We found that Plug-and-Play (\$PNP) and PCI IRQ Routing (\$PIR) functions of SeaBIOS are buggy for Win9x guest. +Steps to reproduce: +1.Install Win98 RTM on QEMU8, it cannot boot to Win98 desktop.<br /> +2.Install WinME on QEMU8, it will stuck on "copying files". +Additional information: + diff --git a/results/classifier/118/graphic/2200 b/results/classifier/118/graphic/2200 new file mode 100644 index 000000000..baff0cf53 --- /dev/null +++ b/results/classifier/118/graphic/2200 @@ -0,0 +1,39 @@ +graphic: 0.837 +debug: 0.643 +device: 0.631 +performance: 0.476 +boot: 0.381 +semantic: 0.363 +register: 0.341 +vnc: 0.244 +socket: 0.224 +files: 0.219 +PID: 0.197 +risc-v: 0.179 +mistranslation: 0.173 +network: 0.168 +arm: 0.153 +peripherals: 0.139 +ppc: 0.095 +user-level: 0.092 +architecture: 0.078 +TCG: 0.072 +VMM: 0.060 +permissions: 0.058 +hypervisor: 0.035 +virtual: 0.028 +assembly: 0.027 +i386: 0.026 +KVM: 0.019 +x86: 0.007 +kernel: 0.006 + +QEMU OpenGL of SDL and GTK not working properly on Windows hosts +Description of problem: +QEMU OpenGL of SDL and GTK not working properly on Windows hosts. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/118/graphic/2202 b/results/classifier/118/graphic/2202 new file mode 100644 index 000000000..9b33294bc --- /dev/null +++ b/results/classifier/118/graphic/2202 @@ -0,0 +1,63 @@ +graphic: 0.899 +files: 0.849 +debug: 0.826 +PID: 0.705 +semantic: 0.676 +ppc: 0.674 +device: 0.630 +x86: 0.564 +performance: 0.481 +user-level: 0.479 +network: 0.438 +arm: 0.408 +permissions: 0.408 +vnc: 0.407 +socket: 0.402 +assembly: 0.401 +i386: 0.390 +architecture: 0.388 +TCG: 0.374 +risc-v: 0.367 +kernel: 0.347 +boot: 0.341 +VMM: 0.336 +register: 0.318 +mistranslation: 0.311 +virtual: 0.291 +hypervisor: 0.246 +peripherals: 0.204 +KVM: 0.174 + +Crash in contrib/elf2dmp +Description of problem: +The elf2dmp program crash. +``` +$ ./contrib/elf2dmp/elf2dmp ./crash_1 /dev/null +Using Linux mmap +[1] 994585 segmentation fault ./contrib/elf2dmp/elf2dmp ./crash_1 /dev/null +``` +Steps to reproduce: +1. build the qemu project following standard steps +2. navigate to the `build` directory and run `./contrib/elf2dmp/elf2dmp ./crash_1 /dev/null` + +The [crash_1](/uploads/d0890c0f8873b8264c417b0f98ee83a4/crash_1) file. +Additional information: +Run in GDB. +``` +$ gdb ./contrib/elf2dmp/elf2dmp +... +(gdb) set args ./crash_1 /dev/null +(gdb) r +Starting program: /data/share/qemu_latest/build/contrib/elf2dmp/elf2dmp ./crash_1 /dev/null +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +Using Linux mmap + +Program received signal SIGSEGV, Segmentation fault. +init_states (qe=0x7fffffff83f0) at ../contrib/elf2dmp/qemu_elf.c:66 +66 Elf64_Nhdr *start = (void *)((uint8_t *)qe->map + phdr[0].p_offset); +(gdb) bt +#0 init_states (qe=0x7fffffff83f0) at ../contrib/elf2dmp/qemu_elf.c:66 +#1 QEMU_Elf_init (qe=qe@entry=0x7fffffff83f0, filename=<optimized out>) at ../contrib/elf2dmp/qemu_elf.c:235 +#2 0x0000555555555508 in main (argc=<optimized out>, argv=0x7fffffffdb58) at ../contrib/elf2dmp/main.c:538 +``` diff --git a/results/classifier/118/graphic/2217 b/results/classifier/118/graphic/2217 new file mode 100644 index 000000000..210368d33 --- /dev/null +++ b/results/classifier/118/graphic/2217 @@ -0,0 +1,31 @@ +graphic: 0.968 +device: 0.884 +performance: 0.818 +mistranslation: 0.735 +boot: 0.719 +ppc: 0.717 +risc-v: 0.648 +user-level: 0.634 +TCG: 0.621 +VMM: 0.618 +debug: 0.614 +semantic: 0.610 +virtual: 0.604 +PID: 0.561 +permissions: 0.502 +KVM: 0.492 +assembly: 0.488 +register: 0.459 +vnc: 0.459 +hypervisor: 0.443 +peripherals: 0.419 +network: 0.405 +i386: 0.382 +x86: 0.317 +arm: 0.313 +architecture: 0.287 +kernel: 0.144 +files: 0.133 +socket: 0.098 + +Changing screen grab diff --git a/results/classifier/118/graphic/2223 b/results/classifier/118/graphic/2223 new file mode 100644 index 000000000..362bc8b60 --- /dev/null +++ b/results/classifier/118/graphic/2223 @@ -0,0 +1,65 @@ +graphic: 0.966 +risc-v: 0.965 +PID: 0.914 +architecture: 0.903 +device: 0.888 +files: 0.887 +ppc: 0.872 +register: 0.861 +peripherals: 0.859 +permissions: 0.857 +virtual: 0.828 +mistranslation: 0.824 +hypervisor: 0.817 +socket: 0.802 +performance: 0.795 +vnc: 0.794 +i386: 0.771 +semantic: 0.766 +debug: 0.755 +x86: 0.716 +arm: 0.696 +network: 0.680 +boot: 0.662 +kernel: 0.615 +TCG: 0.609 +user-level: 0.575 +VMM: 0.549 +assembly: 0.471 +KVM: 0.312 + +Weird behavior on RISC-V code running on QEMU +Description of problem: +I am currently facing some weird problems on a RISC-V project meant to run on the QEMU environment and thought that maybe someone here could give me a light on the subject. The goal is to run a project built on top of one of FreeRTOS' official demo ports that target the 'virt' QEMU board. I ran across a few weird behaviors where code execution would just hang at some point (QEMU would keep execution but the expected terminal output would never come up). I don't have sufficient knowledge to tell whether the issue is with the FreeRTOS port, the RISC-V gnu toolchain or QEMU itself, hence why I am raising my hand for help on all related channels. + +This [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/) contains more details and a sample project that illustrates well one of the problems I've been getting lately (I also give more context about it [here](https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1434)). It basically goes like this: the program **executes fine** when a certain code snippet is encapsulated **within a function**, but "**crashes**" (i.e. hangs) when the same snippet is placed **directly in the main code**: + +```c +for(int i=0; i < NUMBER_OF_ITEMS; i++){ + createAndPushItem(i); + + // the function above does the exact same thing as the commented code below + // yet, the commented code does not work and will crash the program. but why?? + + // int index = priorities[i]; + // void *value = (void *) getValue(i + 1); + // LinkedListItem_t *item = createItem(index, value); + // if(item){ + // push(item, &list); + // } +} +``` + +The scope shouldn't matter at all here, since there is no local variable being used or anything like that. I have tested workarounds like removing compiling optimization (i.e. changing -Os for -O0) and using regular malloc() instead of FreeRTOS' dynamic allocation API, but all without success. Note that even though the project is build on top of the FreeRTOS demo port, no RTOS functionality is used within this code to make it as simple as it gets. +Steps to reproduce: +1. clone this [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/) +2. follow the readme to install the toolchain +3. follow the readme to compile the program and run it +Additional information: +The expected output is supposed to be: + + + +but when one decides to use the commented snippet instead of the function, the program hangs right before sorting the linked list for the first time: + + diff --git a/results/classifier/118/graphic/2225 b/results/classifier/118/graphic/2225 new file mode 100644 index 000000000..e31b422ca --- /dev/null +++ b/results/classifier/118/graphic/2225 @@ -0,0 +1,41 @@ +graphic: 0.813 +device: 0.731 +performance: 0.720 +semantic: 0.612 +permissions: 0.394 +peripherals: 0.370 +mistranslation: 0.366 +network: 0.304 +debug: 0.301 +architecture: 0.284 +boot: 0.260 +user-level: 0.250 +arm: 0.246 +PID: 0.216 +vnc: 0.211 +virtual: 0.208 +i386: 0.208 +risc-v: 0.195 +hypervisor: 0.192 +register: 0.186 +VMM: 0.154 +socket: 0.152 +files: 0.152 +kernel: 0.151 +ppc: 0.126 +x86: 0.122 +TCG: 0.118 +KVM: 0.107 +assembly: 0.082 + +Mouse capture doesn't actually capture (GTK) +Description of problem: +The mouse is never actually captured by the window, you can always move it off screen, and because the guest OS has no awareness of the absolute mouse position there are many situations where you can't actually click something in the guest OS because the host mouse cursor is out of the window so clicking clicks on another program's window. It's unusable. + +It's clear that the problem is that the cursor isn't actually captured, if it ever was then the problem wouldn't occur. When the mouse is "uncaptured" we see the host cursor at all times and the guest cursor simply doesn't move, but when it's """captured""" the guest cursor still moves freely, it's just hidden while hovering the entire window (and not just the guest rectangle but really the whole thing) and the host cursor moves too at its own pace. + +It happens with `-display gtk` but not `-display sdl`. +Steps to reproduce: +1. Launch windowed guest +2. Click on window +3. Try to move mouse out of the window diff --git a/results/classifier/118/graphic/2231 b/results/classifier/118/graphic/2231 new file mode 100644 index 000000000..81681cc8c --- /dev/null +++ b/results/classifier/118/graphic/2231 @@ -0,0 +1,44 @@ +graphic: 0.968 +device: 0.878 +virtual: 0.781 +performance: 0.736 +VMM: 0.695 +vnc: 0.681 +semantic: 0.666 +mistranslation: 0.543 +KVM: 0.539 +risc-v: 0.488 +ppc: 0.427 +network: 0.410 +architecture: 0.409 +hypervisor: 0.407 +debug: 0.399 +PID: 0.376 +socket: 0.351 +permissions: 0.342 +user-level: 0.334 +boot: 0.315 +TCG: 0.297 +i386: 0.265 +peripherals: 0.253 +register: 0.249 +x86: 0.242 +arm: 0.232 +assembly: 0.208 +kernel: 0.160 +files: 0.105 + +GNOME/Mutter - Wayland Fractional Scaling Breaks VM Resolution +Description of problem: +VMs are rendered at a higher resolution than the pixel count of their window, seemingly because mutter is upscaling for fractional scaling. +Steps to reproduce: +1. Enable GNOME Mutter experimental fractional scaling +2. Launch VM +Additional information: +This only occurs when wayland fractional scaling is enabled, not when text is scaled. Since GNOME/mutter accomplishes fractional scaling by upscaling, I think the VM is being told its window has a higher resolution than it actually has, so it is rendering the VM at a higher resolution, which is then displayed at the display's real resolution. + +In the screenshot below, my resolution is 2256 x 1504 and I have set fractional scaling to 125%. It is worth noting (2256 / 1.25) / 3606 is approximately 0.5. + + + +I apologize if the report is unsatisfactory. I will provide more detail if instructed. I tried reporting to GNOME Boxes and Virt-manager, which both use QEMU, but it seems the problem is upstream. diff --git a/results/classifier/118/graphic/2234 b/results/classifier/118/graphic/2234 new file mode 100644 index 000000000..5ad7029da --- /dev/null +++ b/results/classifier/118/graphic/2234 @@ -0,0 +1,53 @@ +graphic: 0.897 +performance: 0.817 +device: 0.814 +user-level: 0.806 +boot: 0.796 +semantic: 0.744 +register: 0.736 +PID: 0.719 +ppc: 0.690 +vnc: 0.656 +socket: 0.576 +kernel: 0.576 +hypervisor: 0.545 +files: 0.522 +risc-v: 0.519 +permissions: 0.511 +i386: 0.507 +network: 0.491 +x86: 0.466 +KVM: 0.452 +architecture: 0.400 +VMM: 0.394 +debug: 0.392 +peripherals: 0.388 +mistranslation: 0.379 +assembly: 0.372 +arm: 0.370 +TCG: 0.302 +virtual: 0.213 + +upon pressing F2 failures in loading the edk2 bios interface app +Description of problem: +Cosmetic, low priority, but maybe easy to fix +Occasional failures to load the edk2 bios interface app +Workaround, retry until success +Steps to reproduce: +1. start qemu +2. press F2 when qemu guest display window pops up. When it works, it brings up the edk2 bios interface. + This bug concerns the case when it does not work + +For reasons not clear, sometimes, after pressing F2, and after qemu registered the key-stroke (F2) and responded by changing the window size, the bios interface loading process seems to abruptly stop at the following guest-display-screen with the following message. +```BdsDxe: Loading Boot0000 "UiApp" From Fv(7CB8BDC9-F8EB-F434-AAEA-3EE4AF6516A1)/FvFile(462CAA21-7614-4503-836E-8AB6F4662311)``` + + +When the bios interface loading process does succeed, it goes to the expected screen: + +Additional information: +Unsure if this sort of bug should go upstream to https://github.com/tianocore/edk2/issues +Herein notifying @kraxel + +Not a measured statistic, but on basis of feeling, I'd qualitatively say 4 out of 5 times it fails to bring up the bios interface. Its a bit frustrating because it feels like one has no control over it and a successful event is left to chance. + +This isn't a recent introduction/regression. I've noticed this since 8.0.0, so its been this way maybe longer. diff --git a/results/classifier/118/graphic/2237 b/results/classifier/118/graphic/2237 new file mode 100644 index 000000000..029e5dcd3 --- /dev/null +++ b/results/classifier/118/graphic/2237 @@ -0,0 +1,69 @@ +semantic: 0.943 +mistranslation: 0.938 +graphic: 0.935 +assembly: 0.923 +TCG: 0.885 +ppc: 0.879 +peripherals: 0.878 +risc-v: 0.876 +hypervisor: 0.874 +VMM: 0.870 +architecture: 0.858 +PID: 0.846 +device: 0.838 +vnc: 0.822 +performance: 0.817 +user-level: 0.816 +virtual: 0.815 +register: 0.812 +KVM: 0.797 +socket: 0.783 +debug: 0.741 +network: 0.740 +arm: 0.739 +permissions: 0.691 +files: 0.685 +boot: 0.620 +x86: 0.583 +kernel: 0.531 +i386: 0.323 + +mirror block job memory leak +Description of problem: +After creating a background mirror job, and then the connection to the mirror target storage be interrupted and writing cannot be performed, the qemu process memory will increase significantly every time the mirror job performs a write. When the target stroage is restored, the data writing will be completed normally, but the memory will not be reduced. +Steps to reproduce: +1. start a virtual machine with libvirt(virsh start file) +2. add a target mirror block dev, configure io timeout to 2 sec(virsh qemu-monitor-command file --pretty '{"execute": "blockdev-add", "arguments": {"driver": "raw", "cache": {"direct": true}, "node-name": "node-target","file": {"driver": "rbd", "conf":"/etc/ceph/ceph.node53.conf", "pool": "test", "image": "rbd1", "auth-client-required": ["none"], "server": [{"host": "10.0.12.53", "port": "6789"}]}}}') +3. create a background mirror block job(virsh qemu-monitor-command file --pretty '{ "execute": "blockdev-mirror", "arguments": {"device": "libvirt-1-format", "target": "node-target", "sync": "full", "copy-mode": "background", "on-target-error": "ignore", "job-id": "job0"}}') +4. wait for the initial full synchronization to complete +5. write a large number of random ios in the virtual machine with the fio program(fio -filename=/dev/vdb -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=4k -size=4G -numjobs=1 -runtime=300 -group_reporting -name=sep) +6. break the connection with the remote storage or shutdown the remote storage while fio program is running(if the connection is interrupted first and then written io, the probability of reproduce is very low) +7. qemu will report an error indicating that io writing failed and try to write again(qemu-kvm: rbd request failed: cmd 1 offset 1421803520 bytes 1048576 flags 0 task.ret -110 (Connection timed out)) +8. use the numastat command to continuously observe the memory usage of the process and find that the heap memory has increased significantly. + +``` +Per-node process memory usage (in MBs) for PID 946492 (qemu-kvm) + Node 0 Total + --------------- --------------- +Huge 2048.00 2048.00 +Heap 2698.13 2698.13 +Stack 0.71 0.71 +Private 781.48 781.48 +---------------- --------------- --------------- +Total 5528.32 5528.32 + +after a while + +Per-node process memory usage (in MBs) for PID 1059068 (qemu-kvm) + Node 0 Total + --------------- --------------- +Huge 2048.00 2048.00 +Heap 21769.94 21769.94 +Stack 0.71 0.71 +Private 827.22 827.22 +---------------- --------------- --------------- +Total 24645.87 24645.87 +``` +Additional information: +libvirt xml: +[file.xml](/uploads/82ff2e410183f94fde7cbaf19e7911dc/file.xml) diff --git a/results/classifier/118/graphic/2240 b/results/classifier/118/graphic/2240 new file mode 100644 index 000000000..b4ad37828 --- /dev/null +++ b/results/classifier/118/graphic/2240 @@ -0,0 +1,34 @@ +graphic: 0.861 +architecture: 0.849 +kernel: 0.848 +device: 0.820 +ppc: 0.760 +semantic: 0.701 +i386: 0.689 +socket: 0.681 +x86: 0.664 +performance: 0.619 +assembly: 0.564 +arm: 0.527 +permissions: 0.490 +mistranslation: 0.461 +network: 0.460 +boot: 0.436 +register: 0.435 +hypervisor: 0.401 +VMM: 0.401 +KVM: 0.391 +TCG: 0.356 +risc-v: 0.350 +vnc: 0.311 +files: 0.284 +PID: 0.278 +peripherals: 0.260 +debug: 0.226 +virtual: 0.172 +user-level: 0.068 + +Please provide useful defaults for machine and cpu +Additional information: +See https://bugs.debian.org/1040212 and https://salsa.debian.org/helmutg/debvm/-/issues/15 for the preceding discussion and +https://salsa.debian.org/helmutg/debvm/-/blob/main/bin/debvm-run and https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/80 for the used machine and cpu values. diff --git a/results/classifier/118/graphic/2242 b/results/classifier/118/graphic/2242 new file mode 100644 index 000000000..5e4305a76 --- /dev/null +++ b/results/classifier/118/graphic/2242 @@ -0,0 +1,44 @@ +x86: 0.993 +graphic: 0.965 +KVM: 0.926 +device: 0.915 +kernel: 0.847 +semantic: 0.766 +user-level: 0.736 +ppc: 0.693 +performance: 0.679 +architecture: 0.648 +files: 0.608 +debug: 0.601 +peripherals: 0.578 +register: 0.553 +network: 0.537 +mistranslation: 0.537 +VMM: 0.492 +permissions: 0.462 +vnc: 0.421 +PID: 0.398 +hypervisor: 0.388 +TCG: 0.321 +risc-v: 0.316 +boot: 0.295 +socket: 0.209 +arm: 0.189 +assembly: 0.150 +virtual: 0.101 +i386: 0.059 + +Hugepages are not released after windows guest shutdown +Description of problem: +* Hugepages are not released after windows guest shutdown (tested with server 2019 and 2022), everything is ok with linux guests +* Issue is present in both cases: shutdown is initiated by guest, and with the qemu monitor command ``system_shutdown`` +* If the guest is configured with 4G as memory size, hugepages not released may vary but in most cases, only 1G are not released +* Host is a x86_64 linux system, with 1G hugepages only : kernel cmline contains ``default_hugepagesz=1G hugepagesz=1G hugepages=88`` +* I've done many tests with qemu components disabled (network, monitor, vnc), issue is still present with basic command line (launched as root) ``qemu-system-x86_64 -cpu host -enable-kvm -smp 4 -machine type=q35,accel=kvm -m 4G -mem-path /mnt/hugepages -drive id=drv0,file=win.qcow2 -nodefaults`` +* Same issue with args in command line, with or without prealloc: + + -m 4G -mem-path /mnt/hugepages [-mem-prealloc] + -m 4G -machine memory-backend=mem0 -object memory-backend-memfd,id=mem0,size=4G,hugetlb=on,hugetlbsize=1G[,prealloc=on] +Additional information: +* Hugepages release process is audited with command ``cat /proc/meminfo`` +* I can't find any online documentation to help to troubleshoot used hugepages : articles suggest to audit /proc/[pid]/smaps, but here, issue is raised after qemu process terminates diff --git a/results/classifier/118/graphic/2244 b/results/classifier/118/graphic/2244 new file mode 100644 index 000000000..9d6ccfddc --- /dev/null +++ b/results/classifier/118/graphic/2244 @@ -0,0 +1,76 @@ +graphic: 0.845 +device: 0.754 +performance: 0.732 +files: 0.715 +ppc: 0.683 +PID: 0.665 +register: 0.633 +debug: 0.628 +mistranslation: 0.624 +i386: 0.608 +peripherals: 0.531 +architecture: 0.451 +hypervisor: 0.416 +arm: 0.403 +user-level: 0.395 +semantic: 0.379 +VMM: 0.376 +socket: 0.321 +permissions: 0.309 +boot: 0.281 +risc-v: 0.238 +vnc: 0.235 +x86: 0.228 +network: 0.209 +kernel: 0.168 +assembly: 0.160 +TCG: 0.133 +KVM: 0.098 +virtual: 0.078 + +Regression in 8.2.90: cpu_physical_memory_snapshot_get_dirty: assertion failed +Description of problem: +On executing the image from QEMU advent calendar 2014, door 12 the following error is shown and QEMU exists. + +On Debian (built on git-repo) +``` +$ qemu-system-i386 oberon/oberon.qcow2 +qemu-system-i386: ../system/physmem.c:948: cpu_physical_memory_snapshot_get_dirty: Zusicherung »start + length <= snap->end« nicht erfüllt. +Abgebrochen +``` +On Windows (built on qemu-9.0.0-rc0.tar.xz) +``` +$ qemu-system-i386 oberon/oberon.qcow2 +ERROR:../qemu-9.0.0-rc0/system/physmem.c:946:cpu_physical_memory_snapshot_get_dirty: assertion failed: (start + length <= snap->end) +Bail out! ERROR:../qemu-9.0.0-rc0/system/physmem.c:946:cpu_physical_memory_snapshot_get_dirty: assertion failed: (start + length <= snap->end) +``` +Steps to reproduce: +1. Retrieve oberon.tar.xz with `wget http://qemu-advent-calendar.org/2014/download/oberon.tar.xz` +2. Extract with `tar -xf oberon.tar.xz` +3. Execute with `qemu-system-i386 oberon/oberon.qcow2` +Additional information: +The same error is shown for QEMU advent calendar 2014, door 15 (Plan 9 from Bell Labs) soon after switch to graphical mode. + +git bisect result: +``` +973a724eb006f674301a0c45f34b3c08dee0fe49 is the first bad commit +commit 973a724eb006f674301a0c45f34b3c08dee0fe49 +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Mon Dec 29 14:48:14 2014 +0100 + + vga: implement horizontal pel panning in graphics modes + + This implements smooth scrolling, as used for example by Commander Keen + and Second Reality. + + Unfortunately, this is not enough to avoid tearing in Commander Keen, + because sometimes the wrong start address is used for a frame. + On real EGA, the panning register is sampled on every line, while + the display start is latched for the next frame at the start of the + vertical retrace. On real VGA, the panning register is also latched, + but at the end of the vertical retrace. It looks like Keen exploits + this by only waiting for horizontal retrace when setting the display + start, but implementing it breaks the 256-color Keen games... + + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> +``` diff --git a/results/classifier/118/graphic/2251 b/results/classifier/118/graphic/2251 new file mode 100644 index 000000000..d47a37626 --- /dev/null +++ b/results/classifier/118/graphic/2251 @@ -0,0 +1,44 @@ +graphic: 0.941 +boot: 0.922 +device: 0.854 +virtual: 0.795 +semantic: 0.791 +ppc: 0.692 +vnc: 0.667 +files: 0.665 +debug: 0.604 +permissions: 0.493 +PID: 0.468 +socket: 0.461 +hypervisor: 0.452 +register: 0.414 +arm: 0.398 +risc-v: 0.385 +performance: 0.296 +mistranslation: 0.273 +VMM: 0.247 +architecture: 0.241 +network: 0.198 +i386: 0.172 +x86: 0.157 +TCG: 0.157 +KVM: 0.073 +user-level: 0.063 +peripherals: 0.057 +kernel: 0.056 +assembly: 0.052 + +Windows 11 VM with VBS enabled crashes +Description of problem: + +Steps to reproduce: +1. Run a Windows 11 VM on a node (both VM domain XML and node capabilities XML is provided below). +2. Enable VBS on the guest. For doing so you can use https://github.com/MicrosoftDocs/windows-itpro-docs/files/4020040/DG_Readinessv3.7.zip. Then, in Windows terminal, run DG_Readiness_Tool_{version}.ps1 -Enable. +3. Reboot the guest. +4. Windows cannot start (see picture below). +Additional information: +- Domain Capabilities: https://pastebin.com/GdQGQ639 +- VMX capabilities: https://pastebin.com/5nbUH0ev +- contents of /proc/cpuinfo: https://pastebin.com/xZM4x89z +- Domain XML: https://pastebin.com/s4VehTXK +- Windows crash at boot: https://ibb.co/Ny1xRbz diff --git a/results/classifier/118/graphic/2252 b/results/classifier/118/graphic/2252 new file mode 100644 index 000000000..4ecb550f9 --- /dev/null +++ b/results/classifier/118/graphic/2252 @@ -0,0 +1,41 @@ +graphic: 0.991 +performance: 0.991 +boot: 0.951 +peripherals: 0.946 +device: 0.936 +architecture: 0.905 +files: 0.897 +semantic: 0.870 +vnc: 0.826 +PID: 0.793 +arm: 0.770 +permissions: 0.764 +register: 0.751 +socket: 0.743 +VMM: 0.734 +assembly: 0.723 +kernel: 0.704 +debug: 0.701 +ppc: 0.692 +hypervisor: 0.670 +network: 0.603 +risc-v: 0.598 +virtual: 0.581 +TCG: 0.570 +mistranslation: 0.518 +user-level: 0.463 +x86: 0.382 +KVM: 0.322 +i386: 0.258 + +Poor VGA graphics when passing through a graphics card to a BIOS guest using the x-vga flag +Description of problem: +When passing through a GPU (in my case an Nvidia RTX 2070 Super) to a guest with BIOS firmware (using the x-vga flag to get a display out in BIOS mode), the VGA graphics used before an operating system loads proper graphics drivers seems to perform very poorly. Some symptoms of this are: GRUB and Windows Boot Manager are invisible, only showing a black screen (not sure if it affects all bootloaders) Windows 7 falls back to the more basic Vista boot animation during startup instead of the proper Starting Windows + orbs animation Windows 7 while using VGA graphics looks very low quality, with a pixelated look and a low color depth (attached below in additional information) Windows 10's setup just shows a black screen and fails to even boot. It seems to just restart after a bit (with any potential errors being invisible) Once graphics drivers are loaded inside Windows 7 or Linux in the guest, everything works fine. Seems like it's a firmware bug maybe? + +I've tested, and QEMU version 8.1 seems to be the last version without this bug, as 8.2 and up all have this issue. I'm not sure if this affects all graphics cards, as I've only tested this on an RTX 2070 super. +Steps to reproduce: +1. Create a guest with SeaBIOS firmware +2. Pass through a graphics card using -vfio-pci +3. Enable the x-vga flag +Additional information: + diff --git a/results/classifier/118/graphic/2260 b/results/classifier/118/graphic/2260 new file mode 100644 index 000000000..bd75da133 --- /dev/null +++ b/results/classifier/118/graphic/2260 @@ -0,0 +1,55 @@ +graphic: 0.973 +device: 0.948 +architecture: 0.938 +PID: 0.904 +debug: 0.898 +arm: 0.885 +ppc: 0.875 +kernel: 0.875 +performance: 0.862 +boot: 0.859 +files: 0.845 +peripherals: 0.804 +socket: 0.765 +assembly: 0.764 +vnc: 0.746 +risc-v: 0.726 +network: 0.720 +permissions: 0.712 +VMM: 0.699 +register: 0.693 +hypervisor: 0.672 +TCG: 0.670 +virtual: 0.663 +user-level: 0.643 +semantic: 0.592 +i386: 0.545 +x86: 0.495 +KVM: 0.460 +mistranslation: 0.341 + +Storage device missing/Not recognized by driver (regression) +Description of problem: +Installation CD boots but can not find any storage/harddrive to install to. +This works in qemu 8.2.2, so it seems like a regression. +Steps to reproduce: +1. +2. +3. +Get virtio iso from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/ + +Install swtpm like: brew install swtpm + +Use CrystalFetch from https://docs.getutm.app/guides/windows/ to download Windows ISO. + +Create storage: qemu-img create -f qcow2 Win11.qcow2 80G + +dd if=/dev/zero of=vars-pflash.raw bs=1M count=64 + +start tpm like: /opt/homebrew/bin/swtpm socket --tpm2 --tpmstate dir=/Users/jonas/qw11arm/mytpm --ctrl type=unixio,path=/Users/jonas/qw11arm/mytpm/swtpm-sock + +start qemu like: \~/qemu/qemu/build/qemu-system-aarch64 --machine virt,virtualization=on --cpu neoverse-n1 --monitor stdio -smp cpus=4,sockets=1,cores=4,threads=1 -m 5G -device nec-usb-xhci -device qemu-xhci -device usb-kbd -device usb-tablet -device usb-storage,drive=windows,serial=windows -drive if=none,id=windows,format=raw,media=cdrom,file=/Users/jonas/ISOs/22631.2861.231204-0538.23H2_NI_RELEASE_SVC_REFRESH_CLIENTCONSUMER_RET_A64FRE_en-us.iso,readonly=on -device virtio-scsi -device scsi-hd,drive=boot,serial=boot -drive if=none,id=boot,format=qcow2,file=./Win11.qcow2 -drive if=pflash,format=raw,unit=0,file=/Users/jonas/qemu/qemu/build/pc-bios/edk2-aarch64-code.fd,readonly=on -drive file=vars-pflash.raw,format=raw,if=pflash,unit=1 -chardev socket,id=chrtpm,path=/Users/jonas/qw11arm/mytpm/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis-device,tpmdev=tpm0 --display cocoa -rtc base=localtime -device ramfb -boot menu=on -device usb-storage,drive=virtio,serial=virtio -drive if=none,id=virtio,format=raw,media=cdrom,file=/Users/jonas/Downloads/virtio-win-0.1.240.iso,readonly=on -nic user,model=virtio-net-pci,mac=52:54:98:76:54:32 + +Adjust paths and be ready to bypass windows checks as described on https://docs.getutm.app/guides/windows/#this-pc-cant-run-windows-11 +Additional information: + diff --git a/results/classifier/118/graphic/2262 b/results/classifier/118/graphic/2262 new file mode 100644 index 000000000..25d4c19e2 --- /dev/null +++ b/results/classifier/118/graphic/2262 @@ -0,0 +1,229 @@ +graphic: 0.861 +arm: 0.846 +performance: 0.843 +virtual: 0.834 +assembly: 0.833 +risc-v: 0.819 +peripherals: 0.817 +register: 0.816 +debug: 0.814 +architecture: 0.808 +TCG: 0.801 +user-level: 0.791 +semantic: 0.788 +ppc: 0.776 +vnc: 0.775 +mistranslation: 0.775 +boot: 0.764 +files: 0.757 +device: 0.754 +permissions: 0.753 +KVM: 0.738 +PID: 0.727 +VMM: 0.727 +hypervisor: 0.715 +x86: 0.698 +kernel: 0.671 +i386: 0.653 +socket: 0.628 +network: 0.622 + +linux-user riscv32: wait4/waitpid returns wrong value +Description of problem: +Background job started by bash shell in riscv32 chroot environment under qemu linux-user emulation hangs indefinitely. + +strace shows repeated waitid flood `waitid(P_ALL, -1, {}, WNOHANG|WEXITED|WSTOPPED|WCONTINUED, NULL) = 0`. +Steps to reproduce: +1. cross compile a riscv32 environment with crossdev on gentoo or other way and chroot into it. +2. run `sleep 1000 &` +3. run `ls` +4. infinite hangs + +I have a small reproducer that I think may uncover the issue, but I am not 100% sure. I also tried running qemu with sanitizers enabled, but it produces no warning. Happy to provide a tar bar of my riscv32 rootfs if needed. + +<details><summary>simple_shell.c</summary> + +``` +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> +#include <string.h> +#include <sys/wait.h> +#include <signal.h> + +#define MAX_LINE 80 /* The maximum length command */ + +#define BACKGROUND 0 +#define FOREGROUND 1 + +struct Job { + pid_t pid; + char command[MAX_LINE]; + int state; // 0 for background, 1 for foreground +}; + +struct Job jobs[10]; // Maximum 10 background jobs +int num_jobs = 0; + +void handle_signal(int signum) { + // Do nothing for now +} + +int launch_process(char **args, int state) { + pid_t pid; + int status; + + pid = fork(); + if (pid == 0) { + // Child process + if (execvp(args[0], args) == -1) { + perror("Error in execvp"); + exit(EXIT_FAILURE); + } + } else if (pid < 0) { + // Error forking + perror("Error forking"); + } else { + // Parent process + if (state == FOREGROUND) { + // Wait for the child process to finish if it's foreground + do { + wait4(pid, &status, WUNTRACED, NULL); + } while (!WIFEXITED(status) && !WIFSIGNALED(status)); + } else { + // Background process, add to jobs list + jobs[num_jobs].pid = pid; + strcpy(jobs[num_jobs].command, args[0]); + jobs[num_jobs].state = BACKGROUND; + num_jobs++; + } + } + return 1; +} + +void bg_command(int job_number) { + // Send SIGCONT signal to a background job + if (kill(jobs[job_number].pid, SIGCONT) == -1) { + perror("kill"); + } else { + jobs[job_number].state = BACKGROUND; + } +} + +void fg_command(int job_number) { + // Bring a background job to foreground + if (kill(jobs[job_number].pid, SIGCONT) == -1) { + perror("kill"); + } else { + jobs[job_number].state = FOREGROUND; + int status; + wait4(jobs[job_number].pid, &status, WUNTRACED, NULL); + } +} + +int main(void) { + char *args[MAX_LINE/2 + 1]; /* command line arguments */ + int should_run = 1; /* flag to determine when to exit program */ + char command[MAX_LINE]; /* buffer to hold the command */ + char *token; /* token for parsing the command */ + + signal(SIGINT, handle_signal); /* Ignore SIGINT for now */ + signal(SIGTSTP, handle_signal); /* Ignore SIGTSTP for now */ + + while (should_run) { + printf("Shell> "); + fflush(stdout); + fgets(command, MAX_LINE, stdin); /* read command from stdin */ + command[strcspn(command, "\n")] = '\0'; /* remove newline character */ + + if (strcmp(command, "exit") == 0) { + should_run = 0; /* exit the shell */ + continue; + } + + if (strcmp(command, "") == 0) { + continue; /* skip empty commands */ + } + + if (strcmp(command, "cd") == 0) { + char *home = getenv("HOME"); + chdir(home); + continue; + } + + if (strcmp(command, "bg") == 0) { + // Run the most recent background job in the background + bg_command(num_jobs - 1); + continue; + } + + if (strcmp(command, "fg") == 0) { + // Bring the most recent background job to foreground + fg_command(num_jobs - 1); + continue; + } + + token = strtok(command, " "); + int i = 0; + while (token != NULL) { + args[i] = token; + token = strtok(NULL, " "); + i++; + } + args[i] = NULL; + + if (strcmp(args[i-1], "&") == 0) { + args[i-1] = NULL; + launch_process(args, BACKGROUND); + } else { + launch_process(args, FOREGROUND); + } + + pid_t tmp; + // Check if any background jobs have finished + for (int j = 0; j < num_jobs; j++) { + if ((tmp = wait4(jobs[j].pid, NULL, WNOHANG, NULL)) > 0) { + printf("[%d] Done\t%s\n", j, jobs[j].command); + // Remove job from list + for (int k = j; k < num_jobs - 1; k++) { + jobs[k] = jobs[k + 1]; + } + num_jobs--; + } + printf("wait4 ret: %d\n", tmp); + } + } + return 0; +} +``` + +</details> + +<details><summary>loop.c</summary> +int main() {while(1){}} +</details> + +1. compile simple_shell.c, statically for simplicity. `riscv32-unknown-gnu-gcc simple_shell.c --static -o shell_riscv32` +2. compile loop.c to riscv32 or x86_64 (x86_64 is simpler with same result) `gcc loop.c --static -o loop` +3. run shell with qemu user +``` +qemu-user-riscv32 ./shell_riscv32 +shell> ./loop & +[0] Done ./sleep_riscv32 +wait4 ret: 98298 +``` +where it is supposed to return 0 on riscv64 or x86 +Additional information: +More context: +This was found on the side when I was trying to track down a riscv32 infinite loop issue with linux-user emulation that has been blocking riscv32 gentoo bootstrap. I am not certain if my reproducer does reproduced that issue, but feels it is close. strace attached to the process repeats, +``` +waitid(P_ALL, -1, {}, WNOHANG|WEXITED, NULL) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 +waitid(P_ALL, -1, ^Cstrace: Process 237805 detached +``` +It appears to be first mentioned here <https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg05475.html>. diff --git a/results/classifier/118/graphic/2269 b/results/classifier/118/graphic/2269 new file mode 100644 index 000000000..24528a259 --- /dev/null +++ b/results/classifier/118/graphic/2269 @@ -0,0 +1,71 @@ +graphic: 0.886 +assembly: 0.866 +architecture: 0.847 +kernel: 0.821 +risc-v: 0.814 +performance: 0.801 +device: 0.786 +peripherals: 0.730 +semantic: 0.671 +PID: 0.608 +debug: 0.599 +permissions: 0.575 +register: 0.460 +ppc: 0.454 +socket: 0.431 +mistranslation: 0.422 +network: 0.420 +files: 0.404 +vnc: 0.380 +VMM: 0.364 +hypervisor: 0.341 +TCG: 0.326 +i386: 0.294 +virtual: 0.293 +user-level: 0.279 +KVM: 0.278 +boot: 0.252 +arm: 0.235 +x86: 0.192 + +RISC-V exit via sifive_test does not work in scripts with -serial stdio +Description of problem: + +Steps to reproduce: +1. Create assembly file `hello.s`: +```as +.section .text +.globl _start +_start: csrr t0, mhartid + bnez t0, _start + li t0, 0x100000 + li t1, 0x5555 + sw t1, 0(t0) +halt: j halt +``` +2. Create linker script `link.ld`: +```ld +OUTPUT_ARCH( "riscv" ) +ENTRY(_start) +SECTIONS +{ + . = 0x80000000; +} +``` +3. Create runner script `./run.sh` (don't forget to `chmod +x`) +```sh +#!/usr/bin/env bash +timeout 10 qemu-system-riscv64 -M virt -display none -serial stdio -bios none -kernel hello +``` +4. Compile into executable: +```sh +riscv64-unknown-elf-gcc -c -mcmodel=medany -fvisibility=hidden -nostartfiles -march=rv64g -mabi=lp64 -o hello.o hello.s +riscv64-unknown-elf-ld hello.o -nostdlib -T link.ld -o hello +``` +5. Dot-source the script - it will immediately exit cleanly +6. Execute the script - it will timeout with exit code 124 +7. Execute the script with redirected stdin, e.g. `./run.sh < ./run.sh` or `echo | ./run.sh` - it will immediately exit cleanly +Additional information: +This issue happens only with `-serial stdio`. Using `chardev:file` or `chardev:null` does not reproduce the issue. Process substitution like `<(echo 'test')` does not seem to work. `cat | ./run.sh` will wait until any line is send, then exit cleanly. This is mainly an issue when using helper test scripts which want to interact with user, as proper CI/UT would redirect serial anyways. + +I have noticed similar behavior with other RISC-V UART device - when running from scripts, there is no output, as if QEMU was waiting for something, even if there is only UART TX, not RX. It does not matter if I actually type in anything or not. diff --git a/results/classifier/118/graphic/2271 b/results/classifier/118/graphic/2271 new file mode 100644 index 000000000..b921219e2 --- /dev/null +++ b/results/classifier/118/graphic/2271 @@ -0,0 +1,46 @@ +graphic: 0.938 +device: 0.914 +peripherals: 0.905 +ppc: 0.868 +architecture: 0.862 +PID: 0.792 +performance: 0.705 +permissions: 0.621 +semantic: 0.591 +debug: 0.552 +kernel: 0.504 +network: 0.487 +arm: 0.471 +socket: 0.445 +hypervisor: 0.444 +register: 0.415 +vnc: 0.407 +x86: 0.399 +TCG: 0.391 +VMM: 0.390 +files: 0.361 +mistranslation: 0.348 +risc-v: 0.333 +user-level: 0.331 +virtual: 0.316 +boot: 0.264 +i386: 0.223 +KVM: 0.220 +assembly: 0.122 + +pci passthrough fails from aarch64 to amd64 guest +Description of problem: +**PCIe device Pass-thru from aarch64 host to amd64 guest fails with the below** + +qemu-system-amd64: -device vfio-pci,host=0003:06:00.0: VFIO_MAP_DMA failed: Invalid argument +qemu-system-amd64: -device vfio-pci,host=0003:06:00.0: vfio 0003:06:00.0: failed to setup container for group 25: memory listener initialization failed: Region pc.ram: vfio_dma_map(0xba4058207210, 0x100000, 0xbff00000, 0xeba70a300000) = -22 (Invalid argument) + +pass-thru with same command line syntax works correctly if the guest is aarch64 (qemu-system-aarch64). + +AMD64 guest VM otherwise works correctly if -device vfio-pci is not used. + +libvirt / virtmanager fail for aarch64 host -> amd64 guest as well. +Steps to reproduce: +1. Unbind pass-thru device from host. +2. Attach pass-thru device to vfio-pci +3. Execute qemu-system-amd64 as above. diff --git a/results/classifier/118/graphic/2276 b/results/classifier/118/graphic/2276 new file mode 100644 index 000000000..766b1b91b --- /dev/null +++ b/results/classifier/118/graphic/2276 @@ -0,0 +1,72 @@ +graphic: 0.992 +performance: 0.887 +architecture: 0.869 +files: 0.853 +hypervisor: 0.831 +device: 0.828 +peripherals: 0.825 +PID: 0.721 +semantic: 0.700 +socket: 0.689 +vnc: 0.676 +ppc: 0.667 +TCG: 0.660 +debug: 0.645 +VMM: 0.622 +virtual: 0.617 +register: 0.590 +network: 0.578 +kernel: 0.565 +i386: 0.560 +x86: 0.546 +risc-v: 0.542 +permissions: 0.525 +KVM: 0.521 +assembly: 0.506 +arm: 0.503 +user-level: 0.489 +mistranslation: 0.438 +boot: 0.407 + +qemu crash for suspend and resume vm while backup disk of vm +Description of problem: + +Steps to reproduce: +1. virsh create vm2.xml +2. virsh backup-begin domid +3. virsh suspend domid +4. sleep 1 && virsh resume domid + +qemu crash +Additional information: +static int blk_do_set_aio_context(BlockBackend *blk, AioContext *new_context, + bool update_root_node, Error **errp) +{ + BlockDriverState *bs = blk_bs(blk); + ThrottleGroupMember *tgm = &blk->public.throttle_group_member; + int ret; + + if (bs) { + bdrv_ref(bs); + + if (update_root_node) { + ret = bdrv_child_try_set_aio_context(bs, new_context, blk->root, + errp); + if (ret < 0) { + bdrv_unref(bs); + return ret; + } + } + if (tgm->throttle_state) { + _ ****bdrv_drained_begin(bs);----- bs->aio_context->lock lock count is 0,so unlock failed**_ + throttle_group_detach_aio_context(tgm); + throttle_group_attach_aio_context(tgm, new_context); + bdrv_drained_end(bs); + } + + bdrv_unref(bs); + } + + blk->ctx = new_context; + return 0; +} diff --git a/results/classifier/118/graphic/2283 b/results/classifier/118/graphic/2283 new file mode 100644 index 000000000..64073d662 --- /dev/null +++ b/results/classifier/118/graphic/2283 @@ -0,0 +1,63 @@ +graphic: 0.829 +debug: 0.793 +architecture: 0.780 +device: 0.747 +peripherals: 0.746 +PID: 0.722 +kernel: 0.722 +performance: 0.707 +mistranslation: 0.691 +x86: 0.690 +TCG: 0.685 +hypervisor: 0.677 +permissions: 0.658 +network: 0.658 +risc-v: 0.641 +arm: 0.626 +i386: 0.617 +virtual: 0.608 +vnc: 0.608 +KVM: 0.604 +files: 0.601 +VMM: 0.592 +boot: 0.590 +user-level: 0.582 +semantic: 0.572 +ppc: 0.562 +assembly: 0.552 +register: 0.530 +socket: 0.526 + +memory leak in virtio-crypto +Description of problem: +The following log reveals it: + +``` +==1878896==ERROR: LeakSanitizer: detected memory leaks + +Direct leak of 48 byte(s) in 1 object(s) allocated from: + #0 0x5646565ec262 in __interceptor_calloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:138:3 + #1 0x7f591ec3bc50 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5ec50) + #2 0x564659227db7 in error_setg_internal qemu/util/error.c:105:5 + #3 0x56465794ad35 in cryptodev_builtin_operation qemu/backends/cryptodev-builtin.c:557:9 + #4 0x5646579550b5 in cryptodev_backend_operation qemu/backends/cryptodev.c:180:16 + #5 0x564657953640 in cryptodev_backend_crypto_operation qemu/backends/cryptodev.c:289:12 + #6 0x56465773a647 in virtio_crypto_handle_request qemu/hw/virtio/virtio-crypto.c:911:19 + #7 0x5646577386a0 in virtio_crypto_handle_dataq qemu/hw/virtio/virtio-crypto.c:938:13 + #8 0x564657734f87 in virtio_crypto_dataq_bh qemu/hw/virtio/virtio-crypto.c:963:9 + #9 0x56465928a6b1 in aio_bh_call qemu/util/async.c:171:5 + #10 0x56465928b58c in aio_bh_poll qemu/util/async.c:218:13 + #11 0x5646591eb398 in aio_dispatch qemu/util/aio-posix.c:423:5 + #12 0x5646592919ce in aio_ctx_dispatch qemu/util/async.c:360:5 + #13 0x7f591ec32d3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55d3a) + +Indirect leak of 36 byte(s) in 1 object(s) allocated from: + #0 0x5646565ec0cd in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3 + #1 0x7f591e488157 in __vasprintf_internal libio/./libio/vasprintf.c:71:30 +``` +Steps to reproduce: +``` +qemu-system-x86_64 -display none -machine accel=qtest -m 512M -machine q35 -nodefaults -object cryptodev-backend-builtin,id=cryptodev0 -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -qtest stdio < /tmp/reproducer +``` + +[reproducer](/uploads/e0161b0d482bc5dac08929d51e70e7fc/reproducer) diff --git a/results/classifier/118/graphic/2288 b/results/classifier/118/graphic/2288 new file mode 100644 index 000000000..0c58dcbe4 --- /dev/null +++ b/results/classifier/118/graphic/2288 @@ -0,0 +1,59 @@ +graphic: 0.944 +device: 0.929 +VMM: 0.871 +files: 0.870 +x86: 0.861 +debug: 0.841 +ppc: 0.831 +PID: 0.819 +vnc: 0.811 +network: 0.785 +arm: 0.784 +permissions: 0.737 +architecture: 0.722 +register: 0.708 +semantic: 0.706 +risc-v: 0.695 +TCG: 0.666 +boot: 0.638 +mistranslation: 0.582 +performance: 0.555 +socket: 0.472 +hypervisor: 0.445 +kernel: 0.320 +user-level: 0.302 +i386: 0.267 +peripherals: 0.245 +virtual: 0.222 +assembly: 0.169 +KVM: 0.150 + +ERROR: Unrecognized host OS (uname -s reports 'Linux') +Description of problem: +Hit "Unrecognized host OS (uname -s reports 'Linux')" ERROR when run configure file on upstream qemu. +Steps to reproduce: +1.Clone repo and compile it + + 1.1 git clone https://gitlab.com/qemu-project/qemu.git + + 1.2 cd qemu + + 1.3 mkdir build + + 1.4 cd build + + 1.5 ../configure --target-list=x86_64-softmmu --enable-debug + +2.The following ERROR message: + +ERROR: Unrecognized host OS (uname -s reports 'Linux') +Additional information: +Cpu information: + +Vendor ID: AuthenticAMD + + BIOS Vendor ID: Advanced Micro Devices, Inc. + + Model name: AMD EPYC 9754 128-Core Processor + + BIOS Model name: AMD EPYC 9754 128-Core Processor diff --git a/results/classifier/118/graphic/2293 b/results/classifier/118/graphic/2293 new file mode 100644 index 000000000..632dd9116 --- /dev/null +++ b/results/classifier/118/graphic/2293 @@ -0,0 +1,65 @@ +graphic: 0.860 +KVM: 0.817 +virtual: 0.793 +permissions: 0.788 +user-level: 0.780 +semantic: 0.780 +debug: 0.761 +hypervisor: 0.759 +register: 0.751 +architecture: 0.746 +performance: 0.745 +peripherals: 0.741 +socket: 0.733 +arm: 0.731 +assembly: 0.728 +ppc: 0.727 +network: 0.717 +TCG: 0.716 +PID: 0.707 +VMM: 0.705 +risc-v: 0.705 +files: 0.690 +device: 0.689 +vnc: 0.676 +x86: 0.659 +mistranslation: 0.619 +kernel: 0.578 +boot: 0.569 +i386: 0.420 + +[u2f-passthru]: pamu2fcfg command will stuck forever in Guest OS of Qemu +Description of problem: +To use FIDO2 user verification we need to run `pamu2fcfg` command which will stuck forever in Guest OS of Qemu + +Passing `-usb -device u2f-passthru,hidraw=/dev/hidraw2` for U2F-Passthrough +Steps to reproduce: +1. Make you have have plugged Yubikey. +2. In Guest shell install package using following command `sudo apt-get install pamu2fcfg` +3. Run $`pamu2fcfg` command will stuck forever. + +**Note:** If I run `pamu2fcfg` in my Ubuntu Host environment it works fine. +Additional information: +**lsusb output:** + +**$lusb** + +Bus 001 Device 002: ID 46f4:0005 **QEMU U2F USB key** + +Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub + +**Debug Details:** + +When pamu2fcfg was launched following will be the call flow. + +[u2f_key_recv_from_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L251 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L251") → [recv_from_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L204 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L204") → [u2f_passthru_recv_from_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L332 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L332") → [u2f_passthru_read](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L305 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L305") → [u2f_passthru_recv_from_host](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L329 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L329") →[ u2f_transaction_get_from_nonce](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L272 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L272") → [u2f_send_to_guest](https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L302 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f-passthru.c#L302") →[ u2f_pending_in_add](https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L207 "https://github.com/qemu/qemu/blob/master/hw/usb/u2f.c#L207") → [main_loop_wait](https://github.com/qemu/qemu/blob/master/system/runstate.c#L783 "https://github.com/qemu/qemu/blob/master/system/runstate.c#L783") (stuck here) + +From above call flow looks like guest is waiting for key. + +Even I have tried enabling U2F support flag in Qemu while building but that one was not helping either. + +**References:** + +https://github.com/Yubico/pam-u2f/tree/main + +https://www.qemu.org/docs/master/system/devices/usb-u2f.html diff --git a/results/classifier/118/graphic/2315 b/results/classifier/118/graphic/2315 new file mode 100644 index 000000000..b3504beb1 --- /dev/null +++ b/results/classifier/118/graphic/2315 @@ -0,0 +1,42 @@ +graphic: 0.992 +mistranslation: 0.903 +virtual: 0.899 +device: 0.800 +architecture: 0.668 +PID: 0.641 +performance: 0.617 +peripherals: 0.616 +vnc: 0.587 +semantic: 0.571 +kernel: 0.538 +hypervisor: 0.437 +ppc: 0.421 +permissions: 0.414 +network: 0.386 +VMM: 0.374 +socket: 0.371 +files: 0.329 +boot: 0.323 +register: 0.308 +debug: 0.305 +KVM: 0.277 +user-level: 0.217 +arm: 0.216 +i386: 0.173 +TCG: 0.151 +risc-v: 0.147 +x86: 0.098 +assembly: 0.039 + +Mouse cursor is flipped / inverted / upside-down with virtio-gpu in some Wayland compositors +Description of problem: +The mouse cursor is flipped: +Steps to reproduce: +1. Install a Linux system with a 6.8.x kernel inside the virtual machine +2. Install sway / wayfire / hyprland, or kwin 6.0.4.1 +3. See the mouse cursor +Additional information: +The [kwin fix](https://invent.kde.org/plasma/kwin/-/commit/a31561c392adf5abcda0284e8049fafcb3701585) just makes use of dumb buffers instead of dmabuf. + +The mouse cursor should be pointing to the maximizing button at the top-right corner: + diff --git a/results/classifier/118/graphic/2316 b/results/classifier/118/graphic/2316 new file mode 100644 index 000000000..4c610105b --- /dev/null +++ b/results/classifier/118/graphic/2316 @@ -0,0 +1,66 @@ +graphic: 0.943 +architecture: 0.920 +kernel: 0.899 +TCG: 0.899 +user-level: 0.897 +vnc: 0.872 +device: 0.866 +performance: 0.863 +debug: 0.858 +ppc: 0.850 +KVM: 0.849 +permissions: 0.842 +arm: 0.829 +semantic: 0.823 +PID: 0.817 +peripherals: 0.788 +socket: 0.767 +files: 0.763 +VMM: 0.762 +network: 0.761 +mistranslation: 0.744 +register: 0.744 +boot: 0.646 +x86: 0.643 +assembly: 0.615 +risc-v: 0.578 +hypervisor: 0.559 +i386: 0.457 +virtual: 0.393 + +aarch64 virt cortex-a53 libc printf (with argument) hello world strange behavior +Description of problem: +My hello world get lost after + +`0x0000000040000370 <+48>: str q0, [sp, #80]` + +in + +``` + 0x1f8: udf #0 + 0x1fc: udf #0 +=> 0x200: udf #0 + 0x204: udf #0 + 0x208: udf #0 + 0x20c: udf #0 + 0x210: udf #0 + 0x214: udf #0 +``` + +By bisecting, I got the last commit OK : v8.2.0-2033-g49fa457ca5 + +``` +$ qemu-system-aarch64 -M virt,secure=on,gic-version=3 -cpu cortex-a53 -kernel aarch64-none-elf-a.elf -serial stdio -display none +printf with an integer : 42 +``` + +But after v8.2.0-2034-g59754f85ed https://gitlab.com/qemu-project/qemu/-/commit/59754f85ed35cbd5f4bf2663ca2136c78d5b2413 (for example with latest v9.0.0-265-gfd87be1dad), it doesn't work anymore. +Steps to reproduce: +1. Build qemu-system-aarch64 with ``./configure --prefix=$PREFIX --target-list=aarch64-softmmu --disable-user --disable-linux-user --disable-bsd-user --enable-kvm --enable-tcg --disable-gnutls --disable-nettle --disable-gtk --disable-iconv --disable-curses --disable-curl --disable-vnc --disable-vnc-jpeg --disable-attr --disable-libusb --disable-opengl --disable-tpm --disable-bzip2 && make -j$(nproc) && make install`` + +2. Run my hello world : ``qemu-system-aarch64 -M virt,secure=on,gic-version=3 -cpu cortex-a53 -kernel aarch64-none-elf-a.elf -serial stdio -display none`` +Additional information: +I provide here the hello world (elf + map). Of course the problem might be that it (qemu and/or hello world) was not built correctly and that everything was working by chance before v8.2.0-2033-g49fa457ca5 +[aarch64-none-elf-a.elf](/uploads/daf7f37aec260c56d4be5fd90554dce3/aarch64-none-elf-a.elf) +[aarch64-none-elf-a.map](/uploads/5564cee13a214e7eb8d6d4bf79f09682/aarch64-none-elf-a.map) +Depending on the investigation, I can provide what's needed to rebuild it. diff --git a/results/classifier/118/graphic/2323 b/results/classifier/118/graphic/2323 new file mode 100644 index 000000000..0c25beb89 --- /dev/null +++ b/results/classifier/118/graphic/2323 @@ -0,0 +1,56 @@ +graphic: 0.822 +device: 0.767 +peripherals: 0.666 +architecture: 0.642 +user-level: 0.577 +files: 0.577 +hypervisor: 0.556 +kernel: 0.553 +performance: 0.543 +debug: 0.531 +ppc: 0.526 +semantic: 0.522 +risc-v: 0.514 +mistranslation: 0.491 +socket: 0.455 +PID: 0.419 +permissions: 0.407 +vnc: 0.403 +boot: 0.369 +register: 0.294 +network: 0.292 +arm: 0.289 +assembly: 0.278 +TCG: 0.230 +VMM: 0.218 +x86: 0.187 +i386: 0.185 +virtual: 0.168 +KVM: 0.089 + +Win/Super key not working correctly under Windows hosts +Description of problem: +I accidentally noticed `Win` key (VK_LWIN) not working correctly on Windows hosts, more specifically: + +1. It is impossible to "hold" `Win`. If one presses and holds `Win`, the guest is spammed with `Win` keypresses, instead of receiving a single `Win` keypress at the point of releasing the button (VK_LWIN button up). +2. It is impossible to make key combinations (shortcuts, hotkeys etc.) that involve the `Win/Super` key. Maybe implicitly solved by fixing #1. + +This behavior is present starting from bc8e883065f36581e4f2352c31a1dfa5f65a82f2 (ui/sdl2: disable SDL_HINT_GRAB_KEYBOARD on Windows). Before it, on the SDL2 keyboard hook `Win/Super` key worked correctly. I demonstrate the problem on Fedora/WinXP, but it affects all guests. +Steps to reproduce: +1. (see additional information) +2. +3. +Additional information: +Short video demonstration on a WinXP guest and a Fedora 39 guest. The qemus used are (qemu-8.0.2 e0968d21e27ef9c406f709180a39a076e786efbe; working correctly) and (qemu-9.0.0 from the release tarball qemu-9.0.0.tar.xz; buggy) + +1. In the WinXP video, I'm pressing and holding the `Win` key for about 3 seconds. In the correct version, the start menu is opened only at the point of release. In the buggy version, the start menu is opened repeatedly tens of times (flickering). You can see the point of release in Nirsoft's KeyboardStateView, when VK_LWIN loses the "pressed" asterisk. + + At the end of the video I'm trying to use the `Win+e` shortcut for WinExplorer. In the buggy version, Outlook is opened instead. This is because the keypresses are processed individually, first `Win` opens the start menu and then `e` opens email application (in this case outlook). In the correct version WinExplorer is opened. + +  +  + +2. In the Fedora video, I'm trying to set up a simple shortcut, I'm pressing on my keyboard `LCTRL+LALT+Super+E`. In the buggy version, the `Super` key is not picked up. All the shortcut combinations involving `Super` are therefore not working. + +  +  diff --git a/results/classifier/118/graphic/2335 b/results/classifier/118/graphic/2335 new file mode 100644 index 000000000..fccc2ff2a --- /dev/null +++ b/results/classifier/118/graphic/2335 @@ -0,0 +1,238 @@ +graphic: 0.919 +semantic: 0.886 +register: 0.877 +TCG: 0.862 +virtual: 0.858 +assembly: 0.852 +debug: 0.843 +peripherals: 0.843 +arm: 0.832 +kernel: 0.803 +PID: 0.803 +user-level: 0.793 +device: 0.792 +VMM: 0.778 +socket: 0.775 +mistranslation: 0.769 +risc-v: 0.763 +permissions: 0.757 +performance: 0.756 +hypervisor: 0.754 +vnc: 0.733 +KVM: 0.729 +ppc: 0.725 +boot: 0.720 +architecture: 0.706 +files: 0.705 +x86: 0.694 +network: 0.671 +i386: 0.358 + +SPICE Worker segfault +Description of problem: +Hello. Sometimes we have an error. kvm randomly crashes. +May 07 16:55:50 vdi1 kernel: SPICE Worker[249326]: segfault at 7f1c8c03af40 ip 00007f1fbbbb2579 sp 00007f1dabbf9d20 error 4 in libc.so.6[7f1fbbb41000+155000] likely on CPU 89 (core 20, socket 1) +Steps to reproduce: +1. +2. +3. +Additional information: +`# coredumpctl info + PID: 249293 (kvm) + UID: 0 (root) + GID: 0 (root) + Signal: 11 (SEGV) + Timestamp: Tue 2024-05-07 16:55:50 MSK (18h ago) + Command Line: /usr/bin/kvm -id 141 -name VDI,debug-threads=on -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/141.qmp,server=on,wait=off -mon chardev=qmp,mode=control -chard> + Executable: /usr/bin/qemu-system-x86_64 + Control Group: /qemu.slice/141.scope + Unit: 141.scope + Slice: qemu.slice + Boot ID: 5cfcd2d515a6425fa3880a61d8cd6bfc + Machine ID: 6e4c2fe391324304a856baa8e6c88002 + Hostname: vdi1 + Storage: /var/lib/systemd/coredump/core.kvm.0.5cfcd2d515a6425fa3880a61d8cd6bfc.249293.1715090150000000.zst (present) + Size on Disk: 2.3G + Message: Process 249293 (kvm) of user 0 dumped core. + + Module libsystemd.so.0 from deb systemd-252.22-1~deb12u1.amd64 + Module libudev.so.1 from deb systemd-252.22-1~deb12u1.amd64 + Stack trace of thread 249326: + #0 0x00007f1fbbbb2579 _int_malloc (libc.so.6 + 0x97579) + #1 0x00007f1fbbbb46e2 __libc_calloc (libc.so.6 + 0x996e2) + #2 0x00007f1fbd3f76d1 g_malloc0 (libglib-2.0.so.0 + 0x5a6d1) + #3 0x00007f1fbdadd7a3 red_get_data_chunks_ptr (libspice-server.so.1 + 0x3e7a3) + #4 0x00007f1fbdaddf6b red_get_data_chunks (libspice-server.so.1 + 0x3ef6b) + #5 0x00007f1fbdadedd9 red_get_copy_ptr (libspice-server.so.1 + 0x3fdd9) + #6 0x00007f1fbdadf1e5 red_get_native_drawable (libspice-server.so.1 + 0x401e5) + #7 0x00007f1fbdaf1a2c red_process_display (libspice-server.so.1 + 0x52a2c) + #8 0x00007f1fbdaf1cb7 worker_source_dispatch (libspice-server.so.1 + 0x52cb7) + #9 0x00007f1fbd3f17a9 g_main_context_dispatch (libglib-2.0.so.0 + 0x547a9) + #10 0x00007f1fbd3f1a38 n/a (libglib-2.0.so.0 + 0x54a38) + #11 0x00007f1fbd3f1cef g_main_loop_run (libglib-2.0.so.0 + 0x54cef) + #12 0x00007f1fbdaf0fa9 red_worker_main (libspice-server.so.1 + 0x51fa9) + #13 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #14 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + + Stack trace of thread 249321: + #0 0x00007f1fbbc18c5b __GI___ioctl (libc.so.6 + 0xfdc5b) + #1 0x000055b3bae626cf kvm_vcpu_ioctl (qemu-system-x86_64 + 0x72b6cf) + #2 0x000055b3bae62ba5 kvm_cpu_exec (qemu-system-x86_64 + 0x72bba5) + #3 0x000055b3bae6408d kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x72d08d) + #4 0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78) + #5 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #6 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + + Stack trace of thread 249327: + #0 0x00007f1fbdac9b48 glz_rgb_alpha_compress_seg (libspice-server.so.1 + 0x2ab48) + #1 0x00007f1fbdacc1cb glz_rgb_alpha_compress (libspice-server.so.1 + 0x2d1cb) + #2 0x00007f1fbdad08ed image_encoders_compress_glz (libspice-server.so.1 + 0x318ed) + #3 0x00007f1fbdaba608 _Z18dcc_compress_imageP20DisplayChannelClientP10SpiceImageP11SpiceBitmapP8DrawableiP20compress_send_data_t (libspice-server.so.1 + 0x1b608) + #4 0x00007f1fbdabb7f5 fill_bits (libspice-server.so.1 + 0x1c7f5) + #5 0x00007f1fbdabca2f red_marshall_qxl_draw_copy (libspice-server.so.1 + 0x1da2f) + #6 0x00007f1fbdabe82b marshall_lossless_qxl_drawable (libspice-server.so.1 + 0x1f82b) + #7 0x00007f1fbdadb5d3 _ZN16RedChannelClient4pushEv (libspice-server.so.1 + 0x3c5d3) + #8 0x00007f1fbdadb700 red_channel_client_event (libspice-server.so.1 + 0x3c700) + #9 0x00007f1fbdac579d spice_watch_dispatch (libspice-server.so.1 + 0x2679d) + #10 0x00007f1fbd3f167f g_main_context_dispatch (libglib-2.0.so.0 + 0x5467f) + #11 0x00007f1fbd3f1a38 n/a (libglib-2.0.so.0 + 0x54a38) + #12 0x00007f1fbd3f1cef g_main_loop_run (libglib-2.0.so.0 + 0x54cef) + #13 0x00007f1fbdaf0fa9 red_worker_main (libspice-server.so.1 + 0x51fa9) + #14 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #15 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + + Stack trace of thread 249324: + #0 0x00007f1fbbc18c5b __GI___ioctl (libc.so.6 + 0xfdc5b) + #1 0x000055b3bae626cf kvm_vcpu_ioctl (qemu-system-x86_64 + 0x72b6cf) + #2 0x000055b3bae62ba5 kvm_cpu_exec (qemu-system-x86_64 + 0x72bba5) + #3 0x000055b3bae6408d kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x72d08d) + #4 0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78) + #5 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #6 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + + Stack trace of thread 249293: + #0 0x00007f1fbbc17256 __ppoll (libc.so.6 + 0xfc256) + #1 0x000055b3bb011dfe ppoll (qemu-system-x86_64 + 0x8dadfe) + #2 0x000055b3bb00f6ee os_host_main_loop_wait (qemu-system-x86_64 + 0x8d86ee) + #3 0x000055b3bac6caa7 qemu_main_loop (qemu-system-x86_64 + 0x535aa7) + #4 0x000055b3bae6cf46 qemu_default_main (qemu-system-x86_64 + 0x735f46) + #5 0x00007f1fbbb4224a __libc_start_call_main (libc.so.6 + 0x2724a) + #6 0x00007f1fbbb42305 __libc_start_main_impl (libc.so.6 + 0x27305) + #7 0x000055b3baa5f0a1 _start (qemu-system-x86_64 + 0x3280a1) + + Stack trace of thread 249322: + #0 0x00007f1fbbc18c5b __GI___ioctl (libc.so.6 + 0xfdc5b) + #1 0x000055b3bae626cf kvm_vcpu_ioctl (qemu-system-x86_64 + 0x72b6cf) + #2 0x000055b3bae62ba5 kvm_cpu_exec (qemu-system-x86_64 + 0x72bba5) + #3 0x000055b3bae6408d kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x72d08d) + #4 0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78) + #5 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #6 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + + Stack trace of thread 249323: + #0 0x00007f1fbbc18c5b __GI___ioctl (libc.so.6 + 0xfdc5b) + #1 0x000055b3bae626cf kvm_vcpu_ioctl (qemu-system-x86_64 + 0x72b6cf) + #2 0x000055b3bae62ba5 kvm_cpu_exec (qemu-system-x86_64 + 0x72bba5) + #3 0x000055b3bae6408d kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x72d08d) + #4 0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78) + #5 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #6 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + + Stack trace of thread 249294: + #0 0x00007f1fbbc1c719 syscall (libc.so.6 + 0x101719) + #1 0x000055b3baffccfa qemu_futex_wait (qemu-system-x86_64 + 0x8c5cfa) + #2 0x000055b3bb006602 call_rcu_thread (qemu-system-x86_64 + 0x8cf602) + #3 0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78) + #4 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #5 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + + Stack trace of thread 249329: + #0 0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96) + #1 0x00007f1fbbba3558 __pthread_cond_wait_common (libc.so.6 + 0x88558) + #2 0x000055b3baffc68b qemu_cond_wait_impl (qemu-system-x86_64 + 0x8c568b) + #3 0x000055b3baa88f2b vnc_worker_thread_loop (qemu-system-x86_64 + 0x351f2b) + #4 0x000055b3baa89bc8 vnc_worker_thread (qemu-system-x86_64 + 0x352bc8) + #5 0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78) + #6 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #7 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + + Stack trace of thread 3982758: + #0 0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96) + #1 0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c) + #2 0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01) + #3 0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0) + #4 0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4) + #5 0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78) + #6 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #7 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + + Stack trace of thread 969111: + #0 0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96) + #1 0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c) + #2 0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01) + #3 0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0) + #4 0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4) + #5 0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78) + #6 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #7 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + + Stack trace of thread 969113: + #0 0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96) + #1 0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c) + #2 0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01) + #3 0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0) + #4 0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4) + #5 0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78) + #6 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #7 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + + Stack trace of thread 969114: + #0 0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96) + #1 0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c) + #2 0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01) + #3 0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0) + #4 0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4) + #5 0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78) + #6 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #7 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + + Stack trace of thread 969112: + #0 0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96) + #1 0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c) + #2 0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01) + #3 0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0) + #4 0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4) + #5 0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78) + #6 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #7 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + + Stack trace of thread 4165267: + #0 0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96) + #1 0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c) + #2 0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01) + #3 0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0) + #4 0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4) + #5 0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78) + #6 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #7 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + + Stack trace of thread 969116: + #0 0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96) + #1 0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c) + #2 0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01) + #3 0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0) + #4 0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4) + #5 0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78) + #6 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #7 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + + Stack trace of thread 969115: + #0 0x00007f1fbbba0e96 __futex_abstimed_wait_common64 (libc.so.6 + 0x85e96) + #1 0x00007f1fbbba383c __pthread_cond_wait_common (libc.so.6 + 0x8883c) + #2 0x000055b3baffbd01 qemu_cond_timedwait_ts (qemu-system-x86_64 + 0x8c4d01) + #3 0x000055b3baffc8a0 qemu_cond_timedwait_impl (qemu-system-x86_64 + 0x8c58a0) + #4 0x000055b3bb0110d4 worker_thread (qemu-system-x86_64 + 0x8da0d4) + #5 0x000055b3baffbb78 qemu_thread_start (qemu-system-x86_64 + 0x8c4b78) + #6 0x00007f1fbbba4134 start_thread (libc.so.6 + 0x89134) + #7 0x00007f1fbbc247dc __clone3 (libc.so.6 + 0x1097dc) + ELF object binary architecture: AMD x86-64` diff --git a/results/classifier/118/graphic/2340 b/results/classifier/118/graphic/2340 new file mode 100644 index 000000000..a5280e286 --- /dev/null +++ b/results/classifier/118/graphic/2340 @@ -0,0 +1,63 @@ +architecture: 0.972 +graphic: 0.952 +performance: 0.888 +ppc: 0.843 +device: 0.774 +kernel: 0.762 +vnc: 0.732 +assembly: 0.717 +risc-v: 0.688 +debug: 0.664 +boot: 0.654 +semantic: 0.628 +peripherals: 0.592 +arm: 0.587 +socket: 0.567 +permissions: 0.530 +PID: 0.491 +register: 0.468 +TCG: 0.463 +network: 0.461 +i386: 0.431 +VMM: 0.428 +files: 0.413 +user-level: 0.341 +KVM: 0.314 +virtual: 0.244 +x86: 0.236 +mistranslation: 0.128 +hypervisor: 0.064 + +SPARC fp operation INVALID trap hangs on offending instruction. +Description of problem: +An IEEE Invalid Operation exception is typically not enabled in programs - but if it is and an Invalid Operation occurs, a hardware TRAP should be generated which eventually becomes a SIGFPE. However, instead, the program seems to hang on the offending instruction, never moving forward. + +This small C example (you'll need a C compiler) demonstrates the problem, by enabling the INValid floating-pt exception, then executing the FDTOI instruction which causes an INValid trap because the floating-pt source operand is too large for the 32-bit integer result . The SPARC V9 manual specifies that exception should happen, so it's correct to generate the trap. However, the program simply hangs on the FDTOI instruction instead of receiving the signal. + +It could be something in trap emulation that is the underlying culprit here - other possible IEEE traps (such as division-by-zero) might similarly fail? + +`#include <ieeefp.h>` + +`main()` + +`{` + + `double val;` + + `int i;` + + `fpsetmask(FP_X_INV);` + + `val = 1000000000000003.0; /* Number that is too large for int */` + + `printf("val is %f\n", val);` + + `i = val;` + + `printf("i is %d\n", i);` + +`}` +Steps to reproduce: +1. Enable IEEE iNValid operation traps in the TEM in the FSR. +2. Generate an instruction that causes an iNValid trap +3. Instruction hangs, no SIGFPE is generated diff --git a/results/classifier/118/graphic/2361 b/results/classifier/118/graphic/2361 new file mode 100644 index 000000000..81cf6f9cc --- /dev/null +++ b/results/classifier/118/graphic/2361 @@ -0,0 +1,43 @@ +graphic: 0.987 +architecture: 0.956 +device: 0.877 +boot: 0.820 +debug: 0.755 +performance: 0.736 +semantic: 0.733 +permissions: 0.583 +PID: 0.558 +mistranslation: 0.544 +arm: 0.483 +user-level: 0.473 +assembly: 0.465 +register: 0.451 +vnc: 0.418 +ppc: 0.372 +risc-v: 0.279 +kernel: 0.242 +files: 0.217 +TCG: 0.213 +virtual: 0.211 +VMM: 0.157 +network: 0.152 +hypervisor: 0.135 +socket: 0.129 +peripherals: 0.108 +KVM: 0.030 +i386: 0.026 +x86: 0.018 + +-cpu host or -cpu max breaks GRUB on AMD +Description of problem: +I'm running the on an AMD Ryzen CPU host. I am emulating a Debian Bookworm image stored in a raw disk. It uses GRUB to load a large (400MB) initrd. When ran with the flag -cpu host or -cpu max, GRUB throws an out of memory error while loading the initrd. This doesn't occur when using -cpu kvm64 or excluding the -cpu flag. + +If I direct boot the initrd and kernel via -initrd and -kernel, it works fine. The image also works with -cpu host on an Intel CPU host machine. The image also works with -cpu EPYC. +Steps to reproduce: +1. Create a raw disk with a large initrd and GRUB boot loader +2. Start a qemu machine on an AMD host +3. Receive an error: out of memory +Additional information: +I could try selectively enabling CPU features, but I was wondering if the maintainers knew of any feature that might be causing this or how to list the features -cpu host enables. + +I also am not 100% that this is a QEMU bug, but it seems the only way to fix it is changing the QEMU config. diff --git a/results/classifier/118/graphic/2376 b/results/classifier/118/graphic/2376 new file mode 100644 index 000000000..de7d86dd7 --- /dev/null +++ b/results/classifier/118/graphic/2376 @@ -0,0 +1,144 @@ +graphic: 0.950 +arm: 0.931 +debug: 0.914 +user-level: 0.903 +hypervisor: 0.892 +architecture: 0.884 +register: 0.880 +TCG: 0.877 +virtual: 0.876 +PID: 0.873 +performance: 0.872 +device: 0.870 +semantic: 0.861 +assembly: 0.853 +risc-v: 0.852 +files: 0.850 +permissions: 0.845 +vnc: 0.842 +boot: 0.827 +network: 0.820 +kernel: 0.804 +socket: 0.798 +VMM: 0.777 +peripherals: 0.776 +x86: 0.766 +KVM: 0.760 +mistranslation: 0.755 +ppc: 0.752 +i386: 0.685 + +A bug in ARM VCMLA.f16/VCMLA.f32 instructions +Description of problem: +The vcmla instruction performs complex-number operations on the vector registers. There is a bug in which this instruction modifies the contents of an irrelevant vector register. + +The reason is simple out-of-bound; the helper functions should correctly check the number of modified elements: +``` +// target/arm/tcg/vec_helper.c +void HELPER(gvec_fcmlah_idx)(void *vd, void *vn, void *vm, void *va, + void *vfpst, uint32_t desc) +{ + uintptr_t opr_sz = simd_oprsz(desc); + float16 *d = vd, *n = vn, *m = vm, *a = va; + float_status *fpst = vfpst; + intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1); + uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1); + intptr_t index = extract32(desc, SIMD_DATA_SHIFT + 2, 2); + uint32_t neg_real = flip ^ neg_imag; + intptr_t elements = opr_sz / sizeof(float16); + intptr_t eltspersegment = 16 / sizeof(float16); // This should be fixed; + intptr_t i, j; + + ... +} + +... + +void HELPER(gvec_fcmlas_idx)(void *vd, void *vn, void *vm, void *va, + void *vfpst, uint32_t desc) +{ + uintptr_t opr_sz = simd_oprsz(desc); + float32 *d = vd, *n = vn, *m = vm, *a = va; + float_status *fpst = vfpst; + intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1); + uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1); + intptr_t index = extract32(desc, SIMD_DATA_SHIFT + 2, 2); + uint32_t neg_real = flip ^ neg_imag; + intptr_t elements = opr_sz / sizeof(float32); + intptr_t eltspersegment = 16 / sizeof(float32); // This should be fixed; + intptr_t i, j; + + ... +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdint.h> +#include <stdio.h> +#include <string.h> + +// zero inputs should produce zero output +char i_D4[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char i_D8[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char i_D30[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char i_D31[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; // this should never be touched +char o_D30[8]; +char o_D31[8]; + +void __attribute__ ((noinline)) show_state() { + printf("D30: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_D30[i]); + } + printf("\n"); + printf("D31: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_D31[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + "movw r7, #:lower16:i_D4\n" + "movt r7, #:upper16:i_D4\n" + "vldr d4, [r7]\n" + "movw r7, #:lower16:i_D8\n" + "movt r7, #:upper16:i_D8\n" + "vldr d8, [r7]\n" + "movw r7, #:lower16:i_D30\n" + "movt r7, #:upper16:i_D30\n" + "vldr d30, [r7]\n" + "movw r7, #:lower16:i_D31\n" + "movt r7, #:upper16:i_D31\n" + "vldr d31, [r7]\n" + "adr r7, Lbl_thumb + 1\n" + "bx r7\n" + ".thumb\n" + "Lbl_thumb:\n" + ".inst 0xfed8e804\n" // vcmla.f32 d30, d8, d4[0], #90 + "adr r7, Lbl_arm\n" + "bx r7\n" + ".arm\n" + "Lbl_arm:\n" + "movw r7, #:lower16:o_D30\n" + "movt r7, #:upper16:o_D30\n" + "vstr d30, [r7]\n" + "movw r7, #:lower16:o_D31\n" + "movt r7, #:upper16:o_D31\n" + "vstr d31, [r7]\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `arm-linux-gnueabihf-gcc-12 -O2 -no-pie -marm -march=armv7-a+vfpv4 ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-arm -L /usr/arm-linux-gnueabihf/ ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints the value of D31 as `00 00 c0 7f 00 00 c0 7f`. It should print `ff ff ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/118/graphic/2382 b/results/classifier/118/graphic/2382 new file mode 100644 index 000000000..4aa377d3f --- /dev/null +++ b/results/classifier/118/graphic/2382 @@ -0,0 +1,44 @@ +graphic: 0.953 +kernel: 0.845 +architecture: 0.838 +device: 0.813 +vnc: 0.690 +semantic: 0.571 +socket: 0.552 +performance: 0.548 +PID: 0.543 +arm: 0.515 +debug: 0.509 +ppc: 0.456 +files: 0.438 +network: 0.416 +risc-v: 0.398 +register: 0.376 +boot: 0.353 +TCG: 0.349 +VMM: 0.310 +user-level: 0.268 +permissions: 0.221 +hypervisor: 0.197 +mistranslation: 0.182 +KVM: 0.141 +virtual: 0.141 +peripherals: 0.130 +x86: 0.129 +i386: 0.103 +assembly: 0.038 + +QEMU occurs an Error when testing my DIY UEFI aarch64 kernel:Synchronous Exception at 0x00000000E46CCEAC +Description of problem: +Shows Synchronous Exception at 0x00000000E46CCEAC and the program halts. +Steps to reproduce: +1.Download the UEFIPascalOS on github. +2.run the bash buildaarch64.sh to build the kernel iso. +3.Go through the installer guide and enter the kernel. +4.Enter the account's name and password and press enter,now you can got an error that shows Synchronous Exception at 0x00000000E46CCEAC +Additional information: +(no logs,stack traces was shown for the error because logs and stack traces are not exists.) +screenshots: + +If I create two accounts,it will halt on sentence "Welcome to TYDQ System!" and give me Synchronous Exception at other numbers. +If I change the memory in virt-machine,the Synchronous Exception showing number will be changed. diff --git a/results/classifier/118/graphic/2387 b/results/classifier/118/graphic/2387 new file mode 100644 index 000000000..16f0a842d --- /dev/null +++ b/results/classifier/118/graphic/2387 @@ -0,0 +1,41 @@ +graphic: 0.907 +device: 0.847 +boot: 0.794 +semantic: 0.658 +performance: 0.650 +architecture: 0.618 +socket: 0.562 +files: 0.543 +debug: 0.479 +virtual: 0.450 +vnc: 0.446 +assembly: 0.419 +risc-v: 0.417 +permissions: 0.399 +register: 0.382 +PID: 0.346 +mistranslation: 0.345 +ppc: 0.330 +peripherals: 0.303 +arm: 0.270 +i386: 0.259 +VMM: 0.244 +user-level: 0.240 +network: 0.239 +TCG: 0.218 +x86: 0.178 +hypervisor: 0.091 +kernel: 0.075 +KVM: 0.008 + +Segmentation fault on booting from ISO when using GTK display with OpenGL enabled +Description of problem: +When trying to boot from the ISO mounted in the `-cdrom` argument, using a GTK display with OpenGL enabled gives a segmentation fault error. If using SDL instead, the whole application kinda freezes most of the times. I managed to get it working once, but I don't know how or why, seemed completely random. After installing it, I can boot from the disk normally with no errors. +Steps to reproduce: +1. Install QEMU for MSYS2 / UCRT64 as described [here](https://www.qemu.org/download/#windows) +2. Download ISO from EndeavourOS website +3. Run `qemu-img create -f qcow2 EndeavourOS.qcow2 64G` to create a disk file +4. Run the script as described above in a `.sh` file +5. See error +Additional information: +I have multiple VMs, included but not limited to Manjaro, Pop!\_OS and Debian, none of them gives this specific error. I also usually avoid SDL because I had multiple issues with the application window completely freezing in the past with "Not responding", and that does not happen with GTK. diff --git a/results/classifier/118/graphic/2399 b/results/classifier/118/graphic/2399 new file mode 100644 index 000000000..2fac13f4f --- /dev/null +++ b/results/classifier/118/graphic/2399 @@ -0,0 +1,57 @@ +graphic: 0.845 +ppc: 0.821 +risc-v: 0.783 +device: 0.777 +PID: 0.757 +debug: 0.739 +performance: 0.738 +x86: 0.715 +i386: 0.701 +architecture: 0.690 +register: 0.689 +peripherals: 0.689 +mistranslation: 0.671 +TCG: 0.670 +files: 0.668 +arm: 0.652 +hypervisor: 0.646 +semantic: 0.642 +permissions: 0.636 +user-level: 0.627 +VMM: 0.625 +vnc: 0.592 +assembly: 0.587 +socket: 0.559 +KVM: 0.556 +virtual: 0.542 +kernel: 0.537 +boot: 0.535 +network: 0.485 + +division by zero in ide +Description of problem: +The following log reveals it: + +``` +../hw/ide/core.c:659:26: runtime error: division by zero +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/ide/core.c:659:26 in AddressSanitizer:DEADLYSIGNAL ================================================================= +==4104568==ERROR：AddressSanitizer：FPE on unknown address 0x559d996a7ec3 (pc 0x559d996a7ec3 bp 0x7ffdcf109da0 sp 0x7ffdcf109a40 T0) +#0 0x559d996a7ec3 in ide_set_sector qemu/hw/ide/core.c:659:26 +#1 0x559d996c8dee in ide_sector_read_cb qemu/hw/ide/core.c:786:5 +#2 0x559d996aa50a in ide_buffered_readv_cb qemu/hw/ide/core.c:684:9 +#3 0x559d9b499289 in blk_aio_complete qemu/block/block-backend.c:1555:9 +#4 0x559d9b4891af in blk_aio_complete_bh qemu/block/block-backend.c:1565:5 +#5 0x559d9bbef6b1 in aio_bh_call qemu/util/async.c:171:5 +#6 0x559d9bbf058c in aio_bh_poll qemu/util/async.c:218:13 +#7 0x559d9bb58a28 in aio_dispatch qemu/util/aio-posix.c:423:5 +#8 0x559d9bbf69ce in aio_ctx_dispatch qemu/util/async.c:360:5 +#9 0x7f51fbc77d3a in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0) +0x55d3a.+0x55d3a) +#10 0x559d9bbfa229 in glib_pollfds_poll qemu/util/main-loop.c:287:9 +#11 0x559d9bbf8b63 in os_host_main_loop_wait qemu/util/main-loop.c:310:5 +#12 0x559d9bbf872c in main_loop_wait qemu/util/main-loop.c:589:11 +#13 0x559d9a2640e7 in qemu_main_loop qemu/system/runstate.c:796:9 +#14 0x559d9b1dcaec in qemu_default_main qemu/system/main.c:37:14 +#15 0x559d9b1dcb37 in main qemu/system/main.c:48:12 +#16 0x7f51fb229d8f in __libc_start_call_main csu/.../sysdeps/nptl/libc_start_call_main.h:58:16 +#17 0x7f51fb229e3f in __libc_start_main csu/../csu/libc-start.c:392:3 #18 0x559d98f20ed4 in _start (/home/joey/repo/qemu/build/qemu-system-x86_64+0x1f93ed4) +``` diff --git a/results/classifier/118/graphic/2403 b/results/classifier/118/graphic/2403 new file mode 100644 index 000000000..58a9690bd --- /dev/null +++ b/results/classifier/118/graphic/2403 @@ -0,0 +1,44 @@ +graphic: 0.984 +device: 0.926 +architecture: 0.871 +x86: 0.870 +boot: 0.867 +vnc: 0.833 +ppc: 0.829 +files: 0.796 +network: 0.775 +socket: 0.758 +peripherals: 0.737 +semantic: 0.727 +performance: 0.633 +mistranslation: 0.625 +permissions: 0.595 +TCG: 0.572 +PID: 0.532 +kernel: 0.531 +arm: 0.508 +user-level: 0.448 +debug: 0.445 +register: 0.443 +risc-v: 0.398 +hypervisor: 0.385 +virtual: 0.306 +i386: 0.299 +VMM: 0.277 +assembly: 0.108 +KVM: 0.018 + +WHPX accelerator fails to boot guest Windows 7 +Description of problem: +I get Qemu freezed on Starting Windows screen when trying to boot Windows 7 Professional +Steps to reproduce: +1. Run qemu with the above command line and until Starting Windows screen appears. +2. See qemu freezed. +Additional information: +tcg accelerator works ok, though (Windows 7 successfully boots as expected on native hardware): + +- `qemu-system-x86_64.exe -accel tcg -cpu Westmere,aes=on,avx=on,sse4.1=on,sse4.2=on,ssse3=on,x2apic=on,xsave=on -m 4G -machine q35 -device qxl-vga,vgamem_mb=64 -hda Windows7_Disk.qcow2 -boot d -cdrom Windows7.iso` + + This bug seems to have the same roots: https://gitlab.com/qemu-project/qemu/-/issues/1859 + + {width=579 height=477} diff --git a/results/classifier/118/graphic/2405 b/results/classifier/118/graphic/2405 new file mode 100644 index 000000000..837920021 --- /dev/null +++ b/results/classifier/118/graphic/2405 @@ -0,0 +1,46 @@ +graphic: 0.898 +files: 0.802 +boot: 0.801 +device: 0.771 +performance: 0.769 +semantic: 0.540 +x86: 0.509 +architecture: 0.428 +mistranslation: 0.407 +ppc: 0.393 +PID: 0.348 +user-level: 0.288 +i386: 0.281 +register: 0.270 +debug: 0.204 +arm: 0.178 +peripherals: 0.158 +vnc: 0.155 +hypervisor: 0.147 +socket: 0.120 +risc-v: 0.120 +network: 0.119 +kernel: 0.106 +VMM: 0.097 +TCG: 0.096 +virtual: 0.086 +KVM: 0.051 +permissions: 0.046 +assembly: 0.033 + +Qemu on Windows fails to parse absolute file path in -acpitable switch +Description of problem: +I expect qemu-system-x86_64.exe to navigate to the path provided with -acpitable switch and to try to parse it. Instead, Qemu prints: "can't open file C: No such file or directory" if provided with absolute path. Qemu thinks "C:" itself is a file with acpi table. + +However, Qemu correctly processes files with relative path. If I run this command to try to parse file COPYING bundled in default qemu build: + +`qemu-system-x86_64.exe -acpitable "file=copying"` + +Qemu says: `qemu-system-x86_64.exe: -acpitable file=copying: warning: ACPI table has wrong length, header says 1313284128, actual size 17992 bytes` + +Then it proceeds to boot BIOS, as usual. +Steps to reproduce: +1. Run `qemu-system-x86_64.exe -acpitable "file=C:\temp\temp.txt"` +2. Experience "can't open file C: No such file or directory" error message returning you to the command prompt. No BIOS screen. +3. Run `qemu-system-x86_64.exe -acpitable "file=copying"` +4. Experience insignificant warning and then a normal BIOS screen. diff --git a/results/classifier/118/graphic/2407 b/results/classifier/118/graphic/2407 new file mode 100644 index 000000000..86ba87d03 --- /dev/null +++ b/results/classifier/118/graphic/2407 @@ -0,0 +1,83 @@ +graphic: 0.911 +user-level: 0.887 +virtual: 0.885 +register: 0.869 +semantic: 0.853 +permissions: 0.848 +architecture: 0.846 +risc-v: 0.846 +arm: 0.844 +performance: 0.842 +device: 0.828 +assembly: 0.814 +boot: 0.796 +mistranslation: 0.790 +debug: 0.790 +PID: 0.765 +files: 0.761 +KVM: 0.756 +x86: 0.755 +kernel: 0.747 +TCG: 0.740 +ppc: 0.722 +peripherals: 0.709 +VMM: 0.707 +socket: 0.696 +network: 0.674 +vnc: 0.659 +hypervisor: 0.628 +i386: 0.624 + +"code should not be reached" in ati_2d_blt() +Description of problem: +My fuzzer detected a "code should not be reached" bug in ati_2d_blt() + +The stack trace is: + +``` +ERROR:include/qemu/bswap.h:418:stn_he_p: code should not be reached +Bail out! ERROR:include/qemu/bswap.h:418:stn_he_p: code should not be reached +==69534== ERROR: libFuzzer: deadly signal + #0 0x559e65667f5e in __sanitizer_print_stack_trace llvm-project-15.0.0.src/compiler-rt/lib/asan/asan_stack.cpp:87:3 + #1 0x559e655a73bc in fuzzer::PrintStackTrace() llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x559e65585a66 in fuzzer::Fuzzer::CrashCallback() (.part.0) llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x559e65585b2b in fuzzer::Fuzzer::CrashCallback() llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x559e65585b2b in fuzzer::Fuzzer::StaticCrashSignalCallback() llvm-project-15.0.0.src/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7fa8835e351f (/lib/x86_64-linux-gnu/libc.so.6+0x4251f) (BuildId: c289da5071a3399de893d2af81d6a30c62646e1e) + #6 0x7fa8836379fb in __pthread_kill_implementation nptl/pthread_kill.c:43:17 + #7 0x7fa8836379fb in __pthread_kill_internal nptl/pthread_kill.c:78:10 + #8 0x7fa8836379fb in pthread_kill nptl/pthread_kill.c:89:10 + #9 0x7fa8835e3475 in gsignal signal/../sysdeps/posix/raise.c:26:13 + #10 0x7fa8835c97f2 in abort stdlib/abort.c:79:7 + #11 0x7fa8848e5b56 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x1eb56) (BuildId: c74e800dfd5f72649d673b44292f4a817e45150b) + #12 0x7fa88493f70e in g_assertion_message_expr (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x7870e) (BuildId: c74e800dfd5f72649d673b44292f4a817e45150b) + #13 0x559e65fc7d70 in stn_he_p include/qemu/bswap.h:418:1 + #14 0x559e65fc55dc in ati_2d_blt hw/display/ati_2d.c:224:21 + #15 0x559e65faccff in ati_mm_write hw/display/ati.c:857:9 + #16 0x559e685b8363 in memory_region_write_accessor system/memory.c:497:5 + #17 0x559e685b7a45 in access_with_adjusted_size system/memory.c:573:18 + #18 0x559e685b59a9 in memory_region_dispatch_write system/memory.c:1521:16 + #19 0x559e6865938e in flatview_write_continue_step system/physmem.c:2757:18 + #20 0x559e68658c24 in flatview_write_continue system/physmem.c:2787:19 + #21 0x559e6863024b in flatview_write system/physmem.c:2818:12 + #22 0x559e6862fd18 in address_space_write system/physmem.c:2938:18 +... +``` +Steps to reproduce: +Arguments: `export QEMU_ARGS="-machine q35 -nodefaults -device ati-vga,romfile=\"\" -display vnc=localhost:99 -L ../pc-bios/"` + +The base addresses of memory regions: + +ati.mmregs: 0xe1000000 + +Reproducer: + +``` +writew 0xe100146c 0x44e4c5c1 +writeb 0xe10016c0 0x773b93cf +writeb 0xe10016e4 0x2beb6e13 +writel 0xe100143c 0x118b71f6 +EOF +``` +Additional information: +Ack: Chuhong Yuan (hslester96@gmail.com) diff --git a/results/classifier/118/graphic/2411 b/results/classifier/118/graphic/2411 new file mode 100644 index 000000000..18843799b --- /dev/null +++ b/results/classifier/118/graphic/2411 @@ -0,0 +1,41 @@ +graphic: 0.972 +peripherals: 0.872 +virtual: 0.859 +architecture: 0.740 +ppc: 0.710 +device: 0.700 +performance: 0.654 +semantic: 0.620 +files: 0.609 +debug: 0.539 +mistranslation: 0.538 +boot: 0.509 +vnc: 0.507 +PID: 0.418 +socket: 0.305 +hypervisor: 0.303 +register: 0.298 +network: 0.267 +permissions: 0.237 +arm: 0.221 +assembly: 0.190 +i386: 0.187 +risc-v: 0.172 +user-level: 0.164 +KVM: 0.141 +VMM: 0.099 +x86: 0.080 +kernel: 0.037 +TCG: 0.031 + +[SPICE] How to make SPICE work with GVT-g + DMA-BUF + egl-headless ? +Description of problem: +I try to use GVT-g + DMA-BUF in PVE , vGPU display output can be displayed normally on noVNC, + +but when I try use SPICE, VM would not boot, come up with error: kvm: **The console requires display DMABUF support**. +Steps to reproduce: +1. Create a windows virtual machine +2. Manually add args to the conf file, add the mdev device of GVT-g. +3. Starting the Virtual Machine + +# diff --git a/results/classifier/118/graphic/2418 b/results/classifier/118/graphic/2418 new file mode 100644 index 000000000..abe5ac3e8 --- /dev/null +++ b/results/classifier/118/graphic/2418 @@ -0,0 +1,42 @@ +graphic: 0.994 +device: 0.783 +boot: 0.736 +virtual: 0.707 +debug: 0.684 +PID: 0.665 +VMM: 0.598 +vnc: 0.556 +files: 0.539 +network: 0.464 +semantic: 0.449 +mistranslation: 0.435 +performance: 0.434 +KVM: 0.396 +hypervisor: 0.352 +register: 0.348 +permissions: 0.331 +architecture: 0.329 +socket: 0.324 +ppc: 0.297 +peripherals: 0.202 +arm: 0.188 +i386: 0.185 +x86: 0.172 +risc-v: 0.167 +TCG: 0.157 +assembly: 0.093 +kernel: 0.070 +user-level: 0.042 + +[Gfxstream BUG] +Description of problem: +I tried to test gfxstream with qemu,I build qemu-9.0.1 with --enable-rutabaga-gfx flag,but after I have compiled and try to boot my Virtual Devices,it crashed and told me with "invalid rutabaga build parameters: gfxstream feature not enabled" + +{width=1276 height=99} +Steps to reproduce: +1.Compile the qemu with kvm,vhost,rutabaga_gfxstream,virgl support +2.run the virtual machine with my command + +But I found an interesting thing:If I build and install AEMU&Gfxstream at /usr in place of /usr/local,I could boot Virtual Machine normally😂 + +Could developers solve the problems?Thanks! diff --git a/results/classifier/118/graphic/2420 b/results/classifier/118/graphic/2420 new file mode 100644 index 000000000..2773b7fb6 --- /dev/null +++ b/results/classifier/118/graphic/2420 @@ -0,0 +1,74 @@ +graphic: 0.966 +virtual: 0.890 +performance: 0.868 +hypervisor: 0.783 +architecture: 0.759 +socket: 0.710 +device: 0.661 +ppc: 0.657 +user-level: 0.627 +mistranslation: 0.562 +arm: 0.546 +vnc: 0.540 +debug: 0.530 +semantic: 0.524 +boot: 0.499 +kernel: 0.497 +peripherals: 0.481 +VMM: 0.450 +x86: 0.428 +PID: 0.416 +network: 0.397 +risc-v: 0.353 +TCG: 0.332 +permissions: 0.302 +i386: 0.280 +KVM: 0.271 +assembly: 0.226 +register: 0.148 +files: 0.100 + +Error: Deprecated CPU topology (considered invalid): Unsupported cluster parameter musn't be specified as 1 +Description of problem: +warning: Deprecated CPU topology (considered invalid): Unsupported clusters parameter mustn't be specified as 1 +VM does not start + +What I've tried so far to fix: + +- Removed the offending `clusters="1"` parameter in the XML, both via virsh edit and virt-manager but the sucker comes back every time! + +- Creating a completely new VM from scratch, just keeping the qcow2 for Windows. What happens then is funny: The initial setup goes well. Machine type automatically gets set to q35 version 9.0. After setting up my cores (pinning) for the VM (7C/14T for the VM 1C/2T for host), there is no "clusters" parameter anymore. So the first start went well. After a RESTART of the whole host machine and subsequent launch of the VM guess what happened? The "clusters" thing is back in full swing. +Steps to reproduce: +1. Create Windows 11 VM with virt-manager +2. Try to do core pinning and setting up the following in virt manager before +- Copy CPU configuration from host (host-passthrough) +- Manually set CPU structure via GUI to 1 Socket, 7 Cores, 2 Threads on an 8 Core (in my case 11900k) +3. Observe result in XML being: + `<topology sockets="1" dies="1" clusters="1" cores="7" threads="2"/>` + +Again, the "clusters" entry leads to the VM not starting. Removing it doesn't work, it comes back straight away. I tried in virt-manager as well as with virsh edit. +Additional information: +My core pinning for reference: + +``` +<vcpu placement="static">14</vcpu> + <iothreads>1</iothreads> + <cputune> + <vcpupin vcpu="0" cpuset="0"/> + <vcpupin vcpu="1" cpuset="8"/> + <vcpupin vcpu="2" cpuset="1"/> + <vcpupin vcpu="3" cpuset="9"/> + <vcpupin vcpu="4" cpuset="2"/> + <vcpupin vcpu="5" cpuset="10"/> + <vcpupin vcpu="6" cpuset="3"/> + <vcpupin vcpu="7" cpuset="11"/> + <vcpupin vcpu="8" cpuset="4"/> + <vcpupin vcpu="9" cpuset="12"/> + <vcpupin vcpu="10" cpuset="5"/> + <vcpupin vcpu="11" cpuset="13"/> + <vcpupin vcpu="12" cpuset="6"/> + <vcpupin vcpu="13" cpuset="14"/> + <emulatorpin cpuset="7,15"/> + <iothreadpin iothread="1" cpuset="7,15"/> + </cputune> +``` diff --git a/results/classifier/118/graphic/2421 b/results/classifier/118/graphic/2421 new file mode 100644 index 000000000..db561e2d8 --- /dev/null +++ b/results/classifier/118/graphic/2421 @@ -0,0 +1,48 @@ +graphic: 0.927 +architecture: 0.886 +semantic: 0.854 +files: 0.847 +device: 0.841 +x86: 0.802 +performance: 0.769 +i386: 0.759 +boot: 0.757 +risc-v: 0.732 +ppc: 0.731 +PID: 0.720 +virtual: 0.713 +arm: 0.710 +register: 0.710 +vnc: 0.706 +socket: 0.691 +permissions: 0.686 +kernel: 0.655 +VMM: 0.649 +user-level: 0.648 +TCG: 0.647 +peripherals: 0.621 +mistranslation: 0.594 +debug: 0.582 +network: 0.501 +hypervisor: 0.485 +assembly: 0.476 +KVM: 0.386 + +Cannot boot ArcaOS 5.1.0 (a distro of OS/2 Warp 4.52) in UEFI mode +Description of problem: +ArcaOS has added the UEFI support since 5.1.0, it has been tested on my physical machine(Ryzen 3300X + RTX2060 Super), and VirtualBox with an `Other x64` machine(the new OS/2 bootloader used in UEFI mode is x64 only). + +Fixes applied to #2198 are perfectly worked in legacy BIOS mode, but if I tried to boot it in UEFI mode, it will stuck on logo screen, and if I enable verbose mode in boot menu, nothing will be shown on the screen and serial ports. + +It happens in both `i440fx` machine type and `q35` machine type. +Steps to reproduce: +1. Install latest qemu HEAD version via `brew install qemu --HEAD` +2. Create new virtual disk via `qemu-img create -f qcow2 hdd.img 20G` +3. Copy EFI bios file and var file + ``` + cp /opt/homebrew/Cellar/qemu/HEAD-1a2d52c/share/qemu/edk2-x86_64-code.fd bios.fd + cp /opt/homebrew/Cellar/qemu/HEAD-1a2d52c/share/qemu/edk2-i386-vars.fd vars.fd + ``` +4. Launch it +Additional information: + diff --git a/results/classifier/118/graphic/2428 b/results/classifier/118/graphic/2428 new file mode 100644 index 000000000..ecd8a5407 --- /dev/null +++ b/results/classifier/118/graphic/2428 @@ -0,0 +1,59 @@ +graphic: 0.839 +device: 0.819 +x86: 0.722 +semantic: 0.627 +ppc: 0.621 +debug: 0.432 +risc-v: 0.397 +PID: 0.386 +vnc: 0.340 +kernel: 0.291 +architecture: 0.272 +boot: 0.262 +TCG: 0.248 +performance: 0.244 +socket: 0.218 +arm: 0.217 +user-level: 0.211 +VMM: 0.210 +mistranslation: 0.175 +KVM: 0.171 +register: 0.137 +i386: 0.134 +files: 0.123 +permissions: 0.119 +network: 0.108 +virtual: 0.107 +peripherals: 0.086 +assembly: 0.047 +hypervisor: 0.032 + +Null-pointer-dereference in ufs +Description of problem: +The following log reveals it: + +``` +../hw/ufs/ufs.c:740:13: runtime error: member access within null pointer of type 'UfsSq' (aka 'struct UfsSq') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/ufs/ufs.c:740:13 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==848760==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000020 (pc 0x6220e29edfce bp 0x7fffea0c6cf0 sp 0x7fffea0c6c40 T0) +==848760==The signal is caused by a READ memory access. +==848760==Hint: address points to the zero page. + #0 0x6220e29edfce in ufs_mcq_process_db hw/ufs/ufs.c:740:9 + #1 0x6220e29dc10f in ufs_write_mcq_op_reg hw/ufs/ufs.c:758:13 + #2 0x6220e29d85c6 in ufs_mmio_write hw/ufs/ufs.c:813:9 +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-x86_64 \ +-display none -machine accel=qtest, -m 512M -M q35 -nodefaults -drive \ +file=null-co://,if=none,id=disk0 -device ufs,id=ufs_bus -device \ +ufs-lu,drive=disk0,bus=ufs_bus -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000804 +outw 0xcfc 0x02 +write 0xe0001004 0x1 0x01 +EOF +``` diff --git a/results/classifier/118/graphic/2429 b/results/classifier/118/graphic/2429 new file mode 100644 index 000000000..0ccdd0914 --- /dev/null +++ b/results/classifier/118/graphic/2429 @@ -0,0 +1,59 @@ +graphic: 0.964 +hypervisor: 0.936 +virtual: 0.895 +mistranslation: 0.875 +permissions: 0.868 +peripherals: 0.857 +socket: 0.851 +performance: 0.848 +PID: 0.845 +register: 0.829 +device: 0.826 +files: 0.807 +x86: 0.796 +arm: 0.793 +risc-v: 0.776 +ppc: 0.763 +assembly: 0.749 +architecture: 0.723 +vnc: 0.700 +TCG: 0.679 +debug: 0.677 +network: 0.663 +semantic: 0.604 +kernel: 0.591 +KVM: 0.587 +i386: 0.583 +user-level: 0.578 +VMM: 0.571 +boot: 0.537 + +Enabling SVM in guest forcefully enables hypervisor flag and doesn't respect hv-vendor-id +Description of problem: +When the SVM cpu feature is enabled in a guest; despite both the hypervisor feature being disabled and hv-vendor-id being set to AuthenticAMD, the guest hypervisor is detected as "Microsoft Hv" and the hypervisor flag is present. Whereas when the SVM cpu feature is disabled but everything else is still the same, the vendor-id is detected as "AuthenticAMD" and the hypervisor flag isn't present, which is exactly as it was intended by the parameters. Therefore, from what I can tell, enabling the SVM cpu feature (which is necessary for nested-virtualization on AMD CPUs) renders hypervisor=off and hv-vendor-id useless by forcefully enabling the hypervisor flag and setting the hypervisor's vendor-id to the default "Microsoft Hv", which normally shouldn't happen. +Steps to reproduce: +1. Run a Windows 11 virtual machine with the given CLI arguments including svm=on +2. I'm not sure how to check the hypervisor vendor from Command Prompt or PowerShell in Windows, so I used [Paranoid Fish](https://github.com/a0rtega/pafish) to check the hypervisor vendor, it's a utility for checking various different VM detection flags in a guest. +3. You should see "Hypervisor: Microsoft Hv" +Additional information: +Screenshot of Paranoid Fish with SVM enabled: + +{width="291" height="86"} ("Hypervisor:" is visible, meaning "-hypervisor" was ignored) + +{width="369" height="13"} (traced means the hypervisor bit is present, meaning `hypervisor=off` was ignored) + +And with SVM disabled: + + ("Hypervisor:" isn't visible, as intended) + +{width="339" height="12"} (OK means the hypervisor bit isn't present, as intended) + +# Solution + +I finally found a solution to this. And it looks like the problem might not even have been on QEMU's side from the beginning. First disabling Virtualization Based Security (Memory Integrity) from settings and then running the following command: `bcdedit /set hypervisorlaunchtype off` in an admin PowerShell fixes the issue and now with SVM enabled, regardless of whether Hyper-V is enabled or not, I see the following CPU information in Paranoid Fish (identical to when SVM was disabled and everything is as intended, and I can still see that virtualization is enabled in task manager): + + + + + +It looks like for some odd reason Windows enables the hypervisor bit on the CPU and sets the hypervisor's vendor-id to "Microsoft Hv" when SVM is enabled in the VM. No clue as to why it does that, but disabling Virtualization Based Security (Memory Integrity) and running the command I mentioned earlier in an admin PowerShell fixes the problem regardless. diff --git a/results/classifier/118/graphic/2437 b/results/classifier/118/graphic/2437 new file mode 100644 index 000000000..575deb3be --- /dev/null +++ b/results/classifier/118/graphic/2437 @@ -0,0 +1,67 @@ +graphic: 0.989 +peripherals: 0.980 +device: 0.968 +VMM: 0.930 +performance: 0.889 +PID: 0.886 +network: 0.874 +virtual: 0.849 +mistranslation: 0.797 +register: 0.793 +user-level: 0.792 +debug: 0.777 +semantic: 0.772 +socket: 0.768 +architecture: 0.741 +arm: 0.705 +ppc: 0.692 +boot: 0.668 +kernel: 0.668 +TCG: 0.655 +permissions: 0.653 +files: 0.652 +vnc: 0.582 +KVM: 0.568 +x86: 0.500 +i386: 0.477 +hypervisor: 0.447 +risc-v: 0.424 +assembly: 0.198 + +qm terminal VMID return "Inappropriate ioctl for device" when spawned by an another process +Description of problem: +as i dont want to mess with vnc i want to use qm terminal to interact with my vms and it doesnt work im currently using nodejs as a test heres the code if anybody wanna try it +```js +import { spawn } from "child_process"; +var child = spawn('qm', ["terminal", "100"]); + +child.stdout.setEncoding('utf8'); +child.stdin.setDefaultEncoding("utf8"); +child.stdout.on('data', function (data) { + console.log('stdout: ' + data.trim()); +}); + +child.stderr.setEncoding('utf8'); +child.stderr.on('data', function (data) { + console.log('stderr: ' + data.trim()); +}); + +child.on('close', function (code) { + console.log('closing code: ' + code); +}); + +setInterval(() => { + child.stdin.write("\n"); +}, 5000); +``` +its just spawning qm terminal and sending return every 5 seconds + +it seems to start but crash + +"Inappropriate ioctl for device" + +{width=478 height=48} + +maybe its not the place to put that but i have no clue so here am i + +At least i tryed spawning something else my code is working diff --git a/results/classifier/118/graphic/2450 b/results/classifier/118/graphic/2450 new file mode 100644 index 000000000..b7cc5c8a1 --- /dev/null +++ b/results/classifier/118/graphic/2450 @@ -0,0 +1,47 @@ +architecture: 0.972 +graphic: 0.962 +device: 0.941 +virtual: 0.882 +files: 0.792 +ppc: 0.779 +x86: 0.702 +PID: 0.693 +semantic: 0.674 +permissions: 0.645 +performance: 0.630 +vnc: 0.610 +boot: 0.601 +socket: 0.591 +peripherals: 0.577 +debug: 0.576 +register: 0.574 +mistranslation: 0.408 +kernel: 0.405 +hypervisor: 0.395 +network: 0.392 +user-level: 0.376 +VMM: 0.335 +arm: 0.331 +TCG: 0.262 +KVM: 0.255 +assembly: 0.183 +risc-v: 0.164 +i386: 0.001 + +Intel GVT-g does not produce any output. +Description of problem: +I'm unable to see anything from screen: +{width=1201 height=956} + +By enabling VGA, I'm able to see the virtual monitor is presented in the guest OS: +{width=977 height=694} + +however it still cannot produce any output: + +{width=977 height=694} +Steps to reproduce: +1. echo "29d65a71-b9eb-45b2-aaaf-49e96f8cf753"> /sys/devices/pci0000:00/*/mdev_supported_types/i915-GVTg_V5_4/create +2. Download the romfile +3. Run the machine +Additional information: +CPU: i7-10700 diff --git a/results/classifier/118/graphic/2453 b/results/classifier/118/graphic/2453 new file mode 100644 index 000000000..0229d9999 --- /dev/null +++ b/results/classifier/118/graphic/2453 @@ -0,0 +1,39 @@ +graphic: 0.964 +device: 0.917 +vnc: 0.894 +permissions: 0.844 +boot: 0.840 +PID: 0.824 +architecture: 0.824 +TCG: 0.822 +files: 0.773 +network: 0.771 +socket: 0.749 +semantic: 0.740 +performance: 0.713 +arm: 0.670 +ppc: 0.654 +register: 0.653 +debug: 0.639 +VMM: 0.581 +virtual: 0.547 +i386: 0.408 +user-level: 0.401 +risc-v: 0.358 +mistranslation: 0.320 +x86: 0.273 +peripherals: 0.175 +KVM: 0.082 +kernel: 0.080 +hypervisor: 0.070 +assembly: 0.068 + +qemu-system-rx aborts when trying to run the u-boot binary +Description of problem: +I tried to run the tests/avocado/machine_rx_gdbsim.py:RxGdbSimMachine.test_uboot test (which is not run by default since it is marked as flaky), but seems like QEMU now always aborts when trying to run with the u-boot bios. +Steps to reproduce: +1. wget https://acc.dl.osdn.jp/users/23/23888/u-boot.bin.gz +2. gunzip u-boot.bin.gz +3. qemu-system-rx -nographic -M gdbsim-r5f562n8 -bios u-boot.bin +Additional information: +Aborts with: ``qemu-system-rx: ../../devel/qemu/accel/tcg/translator.c:286: translator_ld: Assertion `((base ^ pc) & TARGET_PAGE_MASK) == 0' failed.`` diff --git a/results/classifier/118/graphic/2455 b/results/classifier/118/graphic/2455 new file mode 100644 index 000000000..43163c7cc --- /dev/null +++ b/results/classifier/118/graphic/2455 @@ -0,0 +1,38 @@ +graphic: 0.952 +device: 0.926 +x86: 0.900 +performance: 0.781 +debug: 0.741 +network: 0.715 +architecture: 0.646 +semantic: 0.566 +hypervisor: 0.461 +register: 0.455 +kernel: 0.436 +TCG: 0.415 +PID: 0.353 +files: 0.348 +socket: 0.334 +assembly: 0.313 +peripherals: 0.252 +mistranslation: 0.242 +arm: 0.229 +boot: 0.161 +KVM: 0.154 +user-level: 0.133 +vnc: 0.125 +ppc: 0.114 +virtual: 0.088 +VMM: 0.086 +permissions: 0.047 +risc-v: 0.036 +i386: 0.008 + +sdhci: assertion in sdhci_read_dataport() +Description of problem: +The following log reveals it: + +``` +qemu-system-x86_64: qemu/hw/sd/sdhci.c:476: uint32_t sdhci_read_dataport(SDHCIState *, unsigned int): Assertion `s->data_count < s->buf_maxsz' failed. +Aborted (core dumped) +``` diff --git a/results/classifier/118/graphic/2470 b/results/classifier/118/graphic/2470 new file mode 100644 index 000000000..fdcbd84cc --- /dev/null +++ b/results/classifier/118/graphic/2470 @@ -0,0 +1,61 @@ +graphic: 0.898 +peripherals: 0.894 +boot: 0.829 +kernel: 0.814 +device: 0.812 +ppc: 0.761 +socket: 0.712 +architecture: 0.711 +semantic: 0.614 +performance: 0.600 +permissions: 0.578 +register: 0.569 +PID: 0.566 +risc-v: 0.553 +mistranslation: 0.514 +vnc: 0.495 +network: 0.494 +files: 0.490 +user-level: 0.470 +arm: 0.407 +VMM: 0.407 +debug: 0.405 +i386: 0.368 +x86: 0.356 +KVM: 0.341 +TCG: 0.341 +hypervisor: 0.326 +virtual: 0.314 +assembly: 0.215 + +qemu-system-mipsel regression, Linux generated with Buildroot does not boot anymore +Description of problem: +Buildroot Toolchain Builders try to release a new version. See a message from Thomas Petazzoni with the remaining issues: +https://lore.kernel.org/buildroot/20240730223542.273693e5@windsurf/T/#u + +All toolchains generate a system that fails to boot: + +Run /sbin/init as init process +process '/bin/busybox' started with executable stack +Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 + +The interesting thing is that those images boot fine with Qemu v8.2.6, +but they fail to boot with Qemu v9.0.2. + +I tracked it down to this commit: +commit 4e999bf4197ae3dc58b7092260f98146920a7469 +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Sun Jan 28 15:58:52 2024 +1000 + + target/mips: Pass ptw_mmu_idx down from mips_cpu_tlb_fill + + Rather than adjust env->hflags so that the value computed + by cpu_mmu_index() changes, compute the mmu_idx that we + want directly and pass it down. + + Introduce symbolic constants for MMU_{KERNEL,ERL}_IDX. + + Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> + +Unfortunately just reverting this commit in 9.0.2 does not help, Qemu segfaults on Linux Kernel boot then. diff --git a/results/classifier/118/graphic/2486 b/results/classifier/118/graphic/2486 new file mode 100644 index 000000000..01e193bef --- /dev/null +++ b/results/classifier/118/graphic/2486 @@ -0,0 +1,42 @@ +graphic: 0.928 +mistranslation: 0.903 +risc-v: 0.872 +device: 0.758 +architecture: 0.728 +semantic: 0.692 +debug: 0.604 +vnc: 0.583 +performance: 0.541 +PID: 0.507 +network: 0.457 +ppc: 0.438 +permissions: 0.352 +boot: 0.349 +register: 0.336 +kernel: 0.335 +socket: 0.332 +arm: 0.302 +TCG: 0.285 +VMM: 0.260 +i386: 0.209 +files: 0.206 +x86: 0.199 +peripherals: 0.193 +user-level: 0.143 +hypervisor: 0.124 +assembly: 0.109 +virtual: 0.102 +KVM: 0.061 + +RISC-V Regression: QEMU_CPU=f=false,zfinx=true gives misleading error message +Description of problem: +The f extension looks like it should be toggle-able using qemu_cpu since it doesn't throw error messages when specified. +Disabling the extension using f=false does not actually disable it as shown by the zfinx error message. +Eg. Unsupported extension is explicitly rejected +``` +> QEMU_CPU=rv64,j=false ./qemu-riscv64 test.out +qemu-riscv64: can't apply global rv64-riscv-cpu.j=false: Property 'rv64-riscv-cpu.j' not found +``` +Steps to reproduce: +1. Compile any riscv binary like: `int main() {}` +2. Execute using `QEMU_CPU=rv64,zfinx=true,f=false ./qemu-riscv64 test.out` diff --git a/results/classifier/118/graphic/2491 b/results/classifier/118/graphic/2491 new file mode 100644 index 000000000..4ec2baf95 --- /dev/null +++ b/results/classifier/118/graphic/2491 @@ -0,0 +1,45 @@ +graphic: 0.835 +performance: 0.790 +architecture: 0.686 +device: 0.621 +mistranslation: 0.440 +semantic: 0.435 +network: 0.407 +ppc: 0.388 +vnc: 0.371 +files: 0.370 +socket: 0.322 +user-level: 0.315 +VMM: 0.292 +i386: 0.284 +permissions: 0.261 +TCG: 0.260 +x86: 0.256 +kernel: 0.251 +risc-v: 0.221 +arm: 0.215 +virtual: 0.214 +register: 0.212 +PID: 0.199 +boot: 0.197 +peripherals: 0.177 +hypervisor: 0.170 +debug: 0.132 +KVM: 0.122 +assembly: 0.066 + +Performance Regression in QEMU (amd64 Emulating LoongArch64) from 8.0.4 to 9.0.2 +Description of problem: +Previous Performance: In May 2023, we were using QEMU 8.0.4 for qemu-user emulation, and the performance was satisfactory. The setup did not include LSX (Loongson SIMD Extensions) support in either the system or QEMU. Performance results are shown in Figure A. + +Current Performance: Recently, we upgraded to QEMU 9.0.2. Both the system and QEMU now support vectorized instruction sets. However, we observed a performance decline to less than 60% of the previous benchmarks. + +We found that the slowdown is not caused by LSX. Disabling LSX compilation in the new version results in even worse performance. However, there are indeed significant differences between the two systems in terms of LSX support. +Additional information: +We use systemd-nspawn and qemu-binfmt for containerized operations. You can get a clean chroot from lcpu release [here](https://github.com/lcpu-club/loongarchlinux-dockerfile/releases/download/20240806/base-devel-loong64-20240806.tar.zst) + +Figure A, performance in May 2023 + + +Figure B, performance nowadays + diff --git a/results/classifier/118/graphic/2493 b/results/classifier/118/graphic/2493 new file mode 100644 index 000000000..894eace67 --- /dev/null +++ b/results/classifier/118/graphic/2493 @@ -0,0 +1,31 @@ +graphic: 0.806 +device: 0.789 +performance: 0.551 +mistranslation: 0.438 +architecture: 0.401 +VMM: 0.378 +virtual: 0.371 +network: 0.336 +semantic: 0.324 +kernel: 0.295 +hypervisor: 0.259 +i386: 0.242 +peripherals: 0.235 +ppc: 0.232 +files: 0.229 +arm: 0.229 +permissions: 0.215 +PID: 0.214 +x86: 0.180 +TCG: 0.156 +assembly: 0.150 +vnc: 0.129 +debug: 0.099 +boot: 0.096 +user-level: 0.093 +socket: 0.080 +register: 0.066 +risc-v: 0.029 +KVM: 0.013 + +qemu-img delete snapshot by id diff --git a/results/classifier/118/graphic/2496 b/results/classifier/118/graphic/2496 new file mode 100644 index 000000000..2a3c372cf --- /dev/null +++ b/results/classifier/118/graphic/2496 @@ -0,0 +1,63 @@ +graphic: 0.909 +device: 0.875 +debug: 0.732 +network: 0.684 +PID: 0.641 +semantic: 0.632 +register: 0.590 +ppc: 0.585 +kernel: 0.556 +files: 0.537 +vnc: 0.534 +socket: 0.534 +permissions: 0.485 +performance: 0.476 +TCG: 0.464 +hypervisor: 0.434 +architecture: 0.429 +risc-v: 0.393 +peripherals: 0.367 +mistranslation: 0.353 +VMM: 0.344 +arm: 0.260 +boot: 0.255 +user-level: 0.217 +virtual: 0.211 +KVM: 0.207 +assembly: 0.183 +i386: 0.115 +x86: 0.114 + +Regression 9.1.0-rc1: Adventcalendar 2016, Day 14 crashes +Description of problem: +Crashes with + ``` + **** PANIC: **** + terminating with uncaught exception of type hw::Device_not_found: Device of type NIC not found at position #0 + ``` +see [acorn.log](/uploads/daa06857763716183cec625ead619387/acorn.log) for details +Steps to reproduce: +1. Download https://www.qemu-advent-calendar.org/2016/download/day14.tar.xz +2. Execute +Additional information: +git bisect determines: + ``` +64f75f57f9d2c8c12ac6d9355fa5d3a2af5879ca is the first bad commit +commit 64f75f57f9d2c8c12ac6d9355fa5d3a2af5879ca +Author: David Woodhouse <dwmw@amazon.co.uk> +Date: Tue Jul 9 13:34:44 2024 +0100 + + net: Reinstate '-net nic, model=help' output as documented in man page + + While refactoring the NIC initialization code, I broke '-net nic,model=help' + which no longer outputs a list of available NIC models. + + Fixes: 2cdeca04adab ("net: report list of available models according to platform") + Cc: qemu-stable@nongnu.org + Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> + Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> + Signed-off-by: Jason Wang <jasowang@redhat.com> + + net/net.c | 25 ++++++++++++++++++++++--- + 1 file changed, 22 insertions(+), 3 deletions(-) + ``` diff --git a/results/classifier/118/graphic/2502 b/results/classifier/118/graphic/2502 new file mode 100644 index 000000000..5a7f33ad4 --- /dev/null +++ b/results/classifier/118/graphic/2502 @@ -0,0 +1,43 @@ +graphic: 0.984 +architecture: 0.972 +device: 0.899 +semantic: 0.828 +boot: 0.810 +mistranslation: 0.672 +performance: 0.563 +arm: 0.560 +PID: 0.557 +ppc: 0.533 +debug: 0.513 +register: 0.428 +assembly: 0.422 +vnc: 0.391 +risc-v: 0.365 +i386: 0.345 +permissions: 0.303 +files: 0.297 +VMM: 0.258 +TCG: 0.248 +socket: 0.247 +x86: 0.202 +network: 0.196 +peripherals: 0.193 +virtual: 0.117 +kernel: 0.109 +hypervisor: 0.103 +user-level: 0.084 +KVM: 0.058 + +Old amd64 Ubuntu won't start +Description of problem: +While taking a trip down memory lane, I noticed that old Ubuntu amd64 live CDs won't boot in qemu-system-x86_64, while i386 ones work fine. I can confirm this for 6.06 and prior releases, while 8.04 and forward are OK (I don't have interim releases isos). +Steps to reproduce: +1. Launch qemu-system-x86_64 with Ubuntu 6.06.1 amd64 live CD +2. Press "Start or install Ubuntu" +3. PANIC: early exception rip (etc, please see screenshot below) +Additional information: + + +I tried a few versions of QEMU and I can tell you that everything worked fine in 7.0.0 and it first broke in 7.1.0. I don't have a more precise bisect, sorry. I also tried in Fedora 40 with QEMU 8.2.2 and I have the same issue, so I don't think it's distro related. + +On the other hand, on a completely different PC with an Intel Core i3-330M I have no issue at all, even with QEMU 8.2.3, so it might be AMD/Ryzen related. diff --git a/results/classifier/118/graphic/2504 b/results/classifier/118/graphic/2504 new file mode 100644 index 000000000..1eff40279 --- /dev/null +++ b/results/classifier/118/graphic/2504 @@ -0,0 +1,37 @@ +x86: 0.982 +graphic: 0.965 +user-level: 0.940 +device: 0.897 +kernel: 0.787 +architecture: 0.768 +files: 0.738 +network: 0.647 +debug: 0.592 +mistranslation: 0.487 +TCG: 0.446 +vnc: 0.397 +PID: 0.347 +boot: 0.293 +semantic: 0.287 +ppc: 0.253 +VMM: 0.248 +arm: 0.242 +register: 0.206 +performance: 0.183 +socket: 0.145 +permissions: 0.136 +virtual: 0.096 +risc-v: 0.094 +hypervisor: 0.025 +peripherals: 0.021 +assembly: 0.014 +i386: 0.005 +KVM: 0.004 + +linux-user: qemu-x86_64 run /bin/XX got some error on LoongArch machine +Description of problem: +on LoongArch host, chroot x86_64-rootfs then run 'ls' got some error. +Steps to reproduce: +[chrootlog.txt](/uploads/2b77e7d9216396491ef4dc42bf24acc0/chrootlog.txt) +Additional information: + diff --git a/results/classifier/118/graphic/2509 b/results/classifier/118/graphic/2509 new file mode 100644 index 000000000..3c1f377c7 --- /dev/null +++ b/results/classifier/118/graphic/2509 @@ -0,0 +1,56 @@ +graphic: 0.809 +x86: 0.807 +i386: 0.764 +KVM: 0.726 +semantic: 0.700 +device: 0.663 +boot: 0.563 +virtual: 0.479 +files: 0.437 +hypervisor: 0.414 +architecture: 0.400 +PID: 0.378 +mistranslation: 0.362 +network: 0.343 +socket: 0.339 +performance: 0.326 +register: 0.283 +ppc: 0.279 +debug: 0.276 +vnc: 0.275 +user-level: 0.271 +permissions: 0.216 +kernel: 0.204 +risc-v: 0.195 +peripherals: 0.191 +TCG: 0.140 +arm: 0.139 +VMM: 0.135 +assembly: 0.065 + +With qemu-system-i386 certain iso images cause looping crashes +Description of problem: +Soon after start seabios tries to boot, a crash followed by a loop occurs. Last line seen before crash and loop: + ``` +Booting from DVD/CD... + ``` +Steps to reproduce: +1. Download https://www.qemu-advent-calendar.org/2018/download/day10.tar.xz +2. Execute QEMU command line +Additional information: +Starting VM with qemu-system-x86_64 works + ``` + qemu-system-x86_64 -cdrom gamebro.iso + ``` +Starting VM with qemu-system-i386 using KVM causes looping + ``` + qemu-system-i386 -accel kvm -cdrom gamebro.iso + ``` +Starting VM with qemu-system-i386 on Windows using WHPX works + ``` + qemu-system-i386.exe -accel whpx -cdrom gamebro.iso + ``` +Starting other iso images works, e.g. https://cdimage.debian.org/mirror/cdimage/archive/10.8.0/i386/iso-cd/debian-10.8.0-i386-netinst.iso + ``` + qemu-system-i386 -cdrom debian-10.8.0-i386-netinst.iso + ``` diff --git a/results/classifier/118/graphic/2510 b/results/classifier/118/graphic/2510 new file mode 100644 index 000000000..ec0b4d3f3 --- /dev/null +++ b/results/classifier/118/graphic/2510 @@ -0,0 +1,75 @@ +graphic: 0.993 +user-level: 0.978 +performance: 0.976 +x86: 0.973 +semantic: 0.964 +PID: 0.943 +device: 0.931 +mistranslation: 0.918 +peripherals: 0.904 +permissions: 0.901 +architecture: 0.875 +socket: 0.869 +vnc: 0.850 +debug: 0.827 +virtual: 0.826 +TCG: 0.815 +network: 0.803 +ppc: 0.803 +risc-v: 0.792 +files: 0.776 +arm: 0.758 +VMM: 0.750 +KVM: 0.745 +register: 0.734 +hypervisor: 0.692 +boot: 0.635 +kernel: 0.624 +i386: 0.572 +assembly: 0.411 + +Cross compiling tools / qemu-img results in "ninja: no work to do" +Description of problem: +I have the following Dockerfile setting up a cross-compile environment for QEMU. +I am trying to build qemu-img.exe only at the moment + + +``` +FROM fedora as builder +RUN --mount=type=cache,target=/var/cache \ + dnf -v install --assumeyes strace gcc make mingw64-gcc mingw64-binutils python-setuptools meson mingw64-glib2-static mingw64-glib2 diffutils + +FROM builder as qemu-builder +WORKDIR /src/qemu #assuming qemu source tree is already available at /src/qemu +RUN +RUN ./configure --cross-prefix=x86_64-w64-mingw32- --target-list='' --static +RUN make V=1 tools +``` +With either `make tools` or `make qemu-img.exe` I get + +``` +#10 0.265 changing dir to build for make "tools"... +#10 0.267 make[1]: Entering directory '/src/qemu/build' +#10 0.330 ninja: no work to do. +#10 0.331 { \ +#10 0.331 echo 'ninja-targets = \'; \ +#10 0.331 /usr/bin/ninja -t targets all | sed 's/:.*//; $!s/$/ \\/'; \ +#10 0.331 echo 'build-files = \'; \ +#10 0.331 /usr/bin/ninja -t query build.ninja | sed -n '1,/^ input:/d; /^ outputs:/q; s/$/ \\/p'; \ +#10 0.331 } > Makefile.ninja.tmp && mv Makefile.ninja.tmp Makefile.ninja +#10 0.363 /src/qemu/build/pyvenv/bin/meson introspect --targets --tests --benchmarks | /src/qemu/build/pyvenv/bin/python3 -B scripts/mtest2make.py > Makefile.mtest +#10 0.634 make[1]: Nothing to be done for 'tools'. +#10 0.634 make[1]: Leaving directory '/src/qemu/build' +#10 DONE 0.6s +``` + +Following the info in `make help`, I tried `make qemu-img.o` which resulted in + +``` +cc -c -o qemu-img.o qemu-img.c +qemu-img.c:25:10: fatal error: qemu/osdep.h: No such file or directory + 25 | #include "qemu/osdep.h" + | ^~~~~~~~~~~~~~ +``` +Additional information: + diff --git a/results/classifier/118/graphic/2513 b/results/classifier/118/graphic/2513 new file mode 100644 index 000000000..c01ac832c --- /dev/null +++ b/results/classifier/118/graphic/2513 @@ -0,0 +1,43 @@ +graphic: 0.981 +device: 0.979 +x86: 0.934 +ppc: 0.807 +architecture: 0.702 +vnc: 0.617 +performance: 0.613 +files: 0.536 +permissions: 0.498 +network: 0.453 +register: 0.426 +semantic: 0.413 +socket: 0.405 +peripherals: 0.377 +boot: 0.358 +risc-v: 0.358 +kernel: 0.273 +debug: 0.259 +arm: 0.241 +mistranslation: 0.221 +i386: 0.205 +PID: 0.187 +hypervisor: 0.130 +TCG: 0.108 +user-level: 0.088 +assembly: 0.054 +VMM: 0.045 +virtual: 0.022 +KVM: 0.016 + +CXL Device Missing PCI_CAP_ID_PM (01h) in CAP List Implementation According to PCIe SPEC +Description of problem: +- The lack of **PCI_CAP_ID_PM (01h)** will not cause any crash or error when running QEMU, but it is violated to the PCIe SPEC. +- When some vendors test the power management capability (e.g., Linux Runtime PM), they must manually implement this CAP list to support the D1/D2/D3_Hot d-states changes. +- We don't see any PCI_CAP_ID_PM (01h) in the CXL rootport or endpoint + + {width=349 height=474} + + +# +Steps to reproduce: +1. Run the qemu-system-x86 (See QEMU command line) +2. sudo lspci -xxx diff --git a/results/classifier/118/graphic/2518 b/results/classifier/118/graphic/2518 new file mode 100644 index 000000000..184a1a61e --- /dev/null +++ b/results/classifier/118/graphic/2518 @@ -0,0 +1,44 @@ +graphic: 0.963 +debug: 0.958 +performance: 0.935 +kernel: 0.859 +mistranslation: 0.833 +boot: 0.819 +architecture: 0.815 +device: 0.805 +user-level: 0.795 +semantic: 0.768 +permissions: 0.692 +peripherals: 0.666 +network: 0.653 +VMM: 0.551 +register: 0.541 +PID: 0.533 +socket: 0.532 +arm: 0.511 +risc-v: 0.504 +ppc: 0.503 +vnc: 0.471 +files: 0.421 +TCG: 0.354 +hypervisor: 0.329 +x86: 0.289 +i386: 0.246 +assembly: 0.233 +KVM: 0.193 +virtual: 0.192 + +Incorrect vertical mouse leaps on qemu-system-sparc +Description of problem: +In openwin (i.e. X) if you turn the scrollwheel on the mouse 1 click the cursor jumps almost all of the way down the screen. Similarly, just pressing the scroll wheel (middle click) multiple times will sometimes produce similar behavior but the cursor doesn't jump as far. +Steps to reproduce: +- Boot Solaris and log in +- capture the mouse by clicking on the screen +- position the mouse cursor near the top of the screen (just so you can see how far it jumps) +- click the scroll wheel up or down one click and observe the cursor jump downward +Additional information: +The issue is independent of which graphic display is used -- sdl, gtk and vnc all do the same thing. Debugging so far suggests that the problem is related to the fact that `sunmouse_event` in `escc.c` is sending a flood of duplicate events in response to the mouse scroll action. My surmise is that this is causing one byte to be dropped from the 5 byte mouse protocol expected by the Solaris kernel and that it is interpreting a sync byte as a vertical motion byte. + +`sunmouse_event` should not send events with only `dz` non-zero and no button changes. The Mouse Systems Corp spec for the the Sun mouse says that it never sends duplicate events (i.e. an event is produced only if there is non-zero `dx` or `dy` or there has been a button state change), and the mouse protocol has no support for `dz` events. + +I will propose a patch shortly to enforce this (and which has seemingly fixed the problem). diff --git a/results/classifier/118/graphic/2520 b/results/classifier/118/graphic/2520 new file mode 100644 index 000000000..07e5914cc --- /dev/null +++ b/results/classifier/118/graphic/2520 @@ -0,0 +1,41 @@ +x86: 0.975 +graphic: 0.970 +architecture: 0.868 +device: 0.856 +performance: 0.710 +mistranslation: 0.694 +semantic: 0.692 +debug: 0.597 +PID: 0.480 +permissions: 0.394 +files: 0.386 +VMM: 0.326 +vnc: 0.313 +socket: 0.310 +virtual: 0.304 +risc-v: 0.290 +user-level: 0.283 +boot: 0.279 +register: 0.270 +peripherals: 0.202 +i386: 0.159 +TCG: 0.157 +network: 0.152 +hypervisor: 0.152 +ppc: 0.118 +assembly: 0.109 +arm: 0.101 +kernel: 0.056 +KVM: 0.025 + +qemu-system-x86_64 : No Display when system wakeup from suspend +Description of problem: +Qemu display window is blank with message `Display output is not active.` +Steps to reproduce: +1. Use https://gitlab.com/berrange/tiny-vm-tools/-/blob/master/make-tiny-image.py to generate tiny-initrd.img +2. Run qemu and drop into shell +3. Put machine into S3 (echo mem > /sys/power/state) +4. Use socat to connect to QEMU monitor and wake up the machine (system_wakeup) +5. System resumes in shell, but no output in display +Additional information: +Same behavior, if I try standard ubuntu22.04.qcow2 image. Before suspend GUI is there and after wakeup from suspend blank display with message `Display output is not active.` diff --git a/results/classifier/118/graphic/2523 b/results/classifier/118/graphic/2523 new file mode 100644 index 000000000..1009e6678 --- /dev/null +++ b/results/classifier/118/graphic/2523 @@ -0,0 +1,50 @@ +architecture: 0.984 +ppc: 0.967 +graphic: 0.935 +kernel: 0.854 +device: 0.796 +performance: 0.717 +semantic: 0.686 +PID: 0.686 +permissions: 0.613 +files: 0.564 +debug: 0.488 +vnc: 0.479 +mistranslation: 0.477 +socket: 0.436 +TCG: 0.417 +user-level: 0.399 +peripherals: 0.380 +boot: 0.362 +risc-v: 0.345 +hypervisor: 0.330 +network: 0.302 +VMM: 0.280 +register: 0.260 +arm: 0.240 +KVM: 0.136 +virtual: 0.118 +assembly: 0.107 +x86: 0.026 +i386: 0.006 + +[9.0.2] PPC: snapshot replay freeze on PowerPC +Description of problem: +Qemu 9.0.2 cannot replay snapshots on PowerPC e500mc (Book-E) architecture. When I try to do this, the program freezes. +Steps to reproduce: +1. Run bare metal example from the attachment with the first command-line to create snapshot. Then end it using ctrl+c. +2. Run bare metal example from the attachment with the second command-line to replay snapshot. Running will freeze, use ctrl+c. +Additional information: +e500mc example that prints Hello World: [ppc-e500.zip](/uploads/ef9ce53abc3f17490d4894c041956038/ppc-e500.zip) + +Log output: +``` +% qemu-system-ppc -cpu e500 -M ppce500 -kernel hello.elf -display none -serial stdio -icount 1,rr=record,rrfile=main.bin,rrsnapshot=init -drive file=empty.qcow2,if=none,id=rr +Hello world +qemu-system-ppc: terminating on signal 2 +% qemu-system-ppc -cpu e500 -M ppce500 -kernel hello.elf -display none -serial stdio -icount 1,rr=replay,rrfile=main.bin,rrsnapshot=init -drive file=empty.qcow2,if=none,id=rr +qemu-system-ppc: terminating on signal 2 +qemu-system-ppc: Playback shouldn't have to iowait (insn total 0/68 left, event 4 is EVENT_INSTRUCTION) +zsh: IOT instruction (core dumped) qemu-system-ppc -cpu e500 -M ppce500 -kernel hello.elf -display none -serial +``` +`Playback shouldn't have to iowait` error caused by 1f881ea4a444ef36a8b6907b0b82be4b3af253a2 commit, see https://gitlab.com/qemu-project/qemu/-/issues/2524 diff --git a/results/classifier/118/graphic/2524 b/results/classifier/118/graphic/2524 new file mode 100644 index 000000000..076bb68f5 --- /dev/null +++ b/results/classifier/118/graphic/2524 @@ -0,0 +1,33 @@ +graphic: 0.880 +semantic: 0.843 +debug: 0.832 +device: 0.756 +network: 0.676 +ppc: 0.636 +socket: 0.630 +assembly: 0.615 +arm: 0.556 +vnc: 0.545 +kernel: 0.540 +VMM: 0.517 +risc-v: 0.489 +architecture: 0.479 +i386: 0.474 +boot: 0.468 +files: 0.466 +KVM: 0.418 +PID: 0.396 +TCG: 0.389 +mistranslation: 0.362 +x86: 0.356 +hypervisor: 0.301 +register: 0.269 +peripherals: 0.201 +performance: 0.164 +user-level: 0.156 +permissions: 0.153 +virtual: 0.124 + +Reverse debugging is broken on release and stable branches +Description of problem: +Master branch has commit 94962ff00d09674047aed896e87ba09736cd6941, which reverts incorrect commit and fix reverse debugging. But this commit is missing in 9.0.x 9.1.x releases branches and in stable branches too. diff --git a/results/classifier/118/graphic/2543 b/results/classifier/118/graphic/2543 new file mode 100644 index 000000000..f7f3de944 --- /dev/null +++ b/results/classifier/118/graphic/2543 @@ -0,0 +1,41 @@ +graphic: 0.876 +device: 0.792 +boot: 0.619 +performance: 0.609 +risc-v: 0.522 +vnc: 0.496 +architecture: 0.495 +semantic: 0.489 +permissions: 0.449 +files: 0.432 +mistranslation: 0.419 +socket: 0.416 +network: 0.378 +virtual: 0.365 +register: 0.364 +ppc: 0.314 +debug: 0.263 +PID: 0.256 +VMM: 0.241 +arm: 0.217 +user-level: 0.214 +peripherals: 0.167 +x86: 0.132 +TCG: 0.121 +hypervisor: 0.082 +kernel: 0.077 +i386: 0.060 +assembly: 0.035 +KVM: 0.025 + +QEMU UEFI for riscv64 failed to load my DIY bootloader due to unknown reason +Steps to reproduce: +1. [ProblematicBootLoader.zip](/uploads/21fcff0052dc2dd95bf4bba3f6ec8fb8/ProblematicBootLoader.zip) unpack this zipped file,create a fat.img which contains FAT32 file system,and then move the unpacked file in the zip to /EFI/BOOT/bootriscv64.efi.After that using xorriso to pack it. +2. Load the cdrom in libvirt(virt-manager) using SCSI/USB +3. Then wait for seconds and error will show(I don't why STORE_ACCESS_PAGE_FAULT occurs) +Additional information: +My full source code is in https://github.com/TYDQSoft/UEFIPascalOS. + +You can get the instruction in the github to compile this problematic bootloader for testing. + +x64,AArch64 was tested successfully,but riscv64 is always problematic in evert test times. diff --git a/results/classifier/118/graphic/2550 b/results/classifier/118/graphic/2550 new file mode 100644 index 000000000..fcf8f13f4 --- /dev/null +++ b/results/classifier/118/graphic/2550 @@ -0,0 +1,55 @@ +architecture: 0.979 +graphic: 0.967 +arm: 0.932 +boot: 0.931 +device: 0.817 +register: 0.753 +TCG: 0.651 +performance: 0.627 +files: 0.609 +ppc: 0.609 +PID: 0.543 +semantic: 0.534 +kernel: 0.512 +vnc: 0.502 +assembly: 0.444 +user-level: 0.394 +peripherals: 0.389 +virtual: 0.381 +debug: 0.377 +VMM: 0.372 +socket: 0.371 +permissions: 0.317 +risc-v: 0.301 +network: 0.234 +mistranslation: 0.214 +hypervisor: 0.143 +KVM: 0.120 +x86: 0.081 +i386: 0.058 + +GICv3 vGIC system registers not initialized on ARM Cortex-A15 +Description of problem: +For Cortex-A15, the GICv3 vGIC registers are not initialized like for AArch64 CPUs, for example Cotex-A35, Cortex-A55, etc +Steps to reproduce: +The setup is not trivial. I can provide a boot image on request. But I hope the problem is straight-forward. +Additional information: +Suggested fix: +```diff +index 20c2737f17..136b513bda 100644 +--- a/target/arm/tcg/cpu32.c ++++ b/target/arm/tcg/cpu32.c +@@ -569,6 +569,12 @@ static void cortex_a15_initfn(Object *obj) + cpu->ccsidr[1] = 0x201fe00a; /* 32K L1 icache */ + cpu->ccsidr[2] = 0x711fe07a; /* 4096K L2 unified cache */ + cpu->isar.reset_pmcr_el0 = 0x410F3000; ++ ++ /* From B3.5 VGIC Type register */ ++ cpu->gic_num_lrs = 4; ++ cpu->gic_vpribits = 5; ++ cpu->gic_vprebits = 5; ++ + define_arm_cp_regs(cpu, cortexa15_cp_reginfo); + } + +``` diff --git a/results/classifier/118/graphic/2555 b/results/classifier/118/graphic/2555 new file mode 100644 index 000000000..762a1ab8b --- /dev/null +++ b/results/classifier/118/graphic/2555 @@ -0,0 +1,50 @@ +graphic: 0.860 +device: 0.666 +performance: 0.642 +peripherals: 0.604 +semantic: 0.596 +x86: 0.584 +ppc: 0.477 +network: 0.432 +i386: 0.428 +risc-v: 0.421 +kernel: 0.417 +PID: 0.361 +arm: 0.333 +architecture: 0.312 +mistranslation: 0.298 +permissions: 0.295 +vnc: 0.290 +socket: 0.285 +debug: 0.245 +TCG: 0.244 +hypervisor: 0.238 +register: 0.200 +VMM: 0.181 +boot: 0.175 +virtual: 0.150 +KVM: 0.095 +assembly: 0.092 +user-level: 0.035 +files: 0.033 + +Can't start a guest with 2 IOAPICs +Description of problem: +For a host with multiple IOAPICs, I want to start a guest with 2 IOAPICs. I saw this commit about this function: **[x86: add support for second ioapic]**: + https://gitlab.com/qemu-project/qemu/-/commit/94c5a606379ddd04beecdb11fb34b51b4b28c7f2 + +But after I started a guest in a host with multiple IOAPICs, there was still only one IOAPIC in guest. How should I enable this feature? +Additional information: +Host IOAPICs Info: + ``` +[ 1.268280] IOAPIC[0]: apic_id 0, version 33, address 0xfec00000, GSI 0-23 +[ 1.268286] IOAPIC[1]: apic_id 1, version 33, address 0xfec20000, GSI 24-55 +[ 1.268291] IOAPIC[2]: apic_id 2, version 33, address 0xd9000000, GSI 56-87 +[ 4.415313] ACPI: Using IOAPIC for interrupt routing + ``` + +Guest IOAPIC Info: + ``` +[ 0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23 +[ 0.255045] ACPI: Using IOAPIC for interrupt routing + ``` diff --git a/results/classifier/118/graphic/2556 b/results/classifier/118/graphic/2556 new file mode 100644 index 000000000..1ace9f3c1 --- /dev/null +++ b/results/classifier/118/graphic/2556 @@ -0,0 +1,42 @@ +graphic: 0.953 +performance: 0.928 +device: 0.889 +boot: 0.763 +semantic: 0.664 +register: 0.636 +vnc: 0.572 +PID: 0.565 +mistranslation: 0.521 +risc-v: 0.502 +VMM: 0.425 +socket: 0.410 +architecture: 0.408 +i386: 0.403 +x86: 0.385 +debug: 0.383 +kernel: 0.370 +ppc: 0.355 +TCG: 0.346 +arm: 0.337 +user-level: 0.336 +assembly: 0.333 +hypervisor: 0.266 +KVM: 0.228 +network: 0.167 +virtual: 0.136 +permissions: 0.126 +files: 0.106 +peripherals: 0.096 + +memory balloon massively slows Windows shutdown (almost feels like it crashed for minutes) +Description of problem: +When reducing the memory using ballooning, the shutdown takes very long. One may even assume it crashed, but it will eventually power off. +Steps to reproduce: +1. wait until Windows has booted +2. reduce the balloon by multiple GB via monitor: `balloon 8192` _(8 GB balloon, memory size is 24 GB)_ +3. Shut down (or reboot) Windows + +The system shows the boot screen at shutdown for a long time. + +It's about 10 seconds extra time per reduced balloon size. So when resizing the balloon from 24 GB to 8 GB, that's 16 GB. +So the shutdown needs: 16 * 10 = 160 seconds = **about 3 minutes** diff --git a/results/classifier/118/graphic/2559 b/results/classifier/118/graphic/2559 new file mode 100644 index 000000000..db2b6e267 --- /dev/null +++ b/results/classifier/118/graphic/2559 @@ -0,0 +1,41 @@ +graphic: 0.924 +architecture: 0.868 +device: 0.848 +ppc: 0.832 +semantic: 0.824 +arm: 0.795 +PID: 0.708 +files: 0.706 +peripherals: 0.706 +user-level: 0.671 +performance: 0.660 +vnc: 0.609 +permissions: 0.608 +debug: 0.601 +hypervisor: 0.594 +TCG: 0.592 +boot: 0.585 +risc-v: 0.563 +VMM: 0.525 +socket: 0.523 +x86: 0.508 +i386: 0.504 +register: 0.503 +kernel: 0.460 +network: 0.406 +mistranslation: 0.352 +virtual: 0.216 +assembly: 0.173 +KVM: 0.060 + +macOS cocoa UI cursor position mismatch when running Windows XP under QEMU 9.1.0 +Description of problem: +QEMU 9.1.0 got hardware cursor support on macOS with the cocoa UI. When running a Windows XP guest, the windows's own cursor got a 13 pixel offset both in X and Y direction. When the "show-cursor" is off, the problem still exists, so the click target is not under the pointer of the cursor. I was using the "Red Hat QXL GPU" driver v6.1.0.10024 which was built in 2015. + +I also checked it with Linux (i have an x86-64 Alma Linux 8 installation too), this working fine when using the "-display cocoa,show-cursoor=off,zoom-to-fit=off -device virtio-vga" parameters. +Steps to reproduce: +1. Load a Windows XP with QXL drivers installed +Additional information: + + + diff --git a/results/classifier/118/graphic/2577 b/results/classifier/118/graphic/2577 new file mode 100644 index 000000000..e4e4c7edf --- /dev/null +++ b/results/classifier/118/graphic/2577 @@ -0,0 +1,31 @@ +graphic: 0.856 +device: 0.802 +assembly: 0.760 +architecture: 0.501 +x86: 0.481 +kernel: 0.479 +arm: 0.388 +mistranslation: 0.331 +debug: 0.294 +performance: 0.292 +i386: 0.278 +KVM: 0.276 +hypervisor: 0.187 +ppc: 0.175 +semantic: 0.160 +peripherals: 0.135 +VMM: 0.135 +risc-v: 0.122 +files: 0.121 +boot: 0.117 +virtual: 0.116 +network: 0.105 +register: 0.089 +socket: 0.084 +vnc: 0.067 +user-level: 0.057 +TCG: 0.051 +permissions: 0.045 +PID: 0.040 + +buildx: Illegal instruction, exit code: 132 diff --git a/results/classifier/118/graphic/2580 b/results/classifier/118/graphic/2580 new file mode 100644 index 000000000..5c1b57723 --- /dev/null +++ b/results/classifier/118/graphic/2580 @@ -0,0 +1,42 @@ +graphic: 0.955 +device: 0.917 +PID: 0.876 +network: 0.776 +performance: 0.748 +vnc: 0.716 +architecture: 0.716 +debug: 0.703 +boot: 0.681 +TCG: 0.647 +semantic: 0.637 +mistranslation: 0.599 +permissions: 0.583 +socket: 0.572 +kernel: 0.566 +ppc: 0.544 +files: 0.524 +arm: 0.500 +VMM: 0.369 +register: 0.363 +user-level: 0.313 +risc-v: 0.262 +virtual: 0.261 +hypervisor: 0.143 +peripherals: 0.114 +KVM: 0.097 +x86: 0.082 +i386: 0.071 +assembly: 0.058 + +qemu-aarch64_be 9.1.0 fails to run any Linux programs due to unreachable in gdb_find_static_feature() +Description of problem: +``` +❯ cat empty.c +void _start() {} +❯ clang empty.c -target aarch64_be-linux -nostdlib -fuse-ld=lld +❯ qemu-aarch64_be ./a.out +** +ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached +Bail out! ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached +fish: Job 1, 'qemu-aarch64_be ./a.out' terminated by signal SIGABRT (Abort) +``` diff --git a/results/classifier/118/graphic/2591 b/results/classifier/118/graphic/2591 new file mode 100644 index 000000000..65cb55bc9 --- /dev/null +++ b/results/classifier/118/graphic/2591 @@ -0,0 +1,31 @@ +graphic: 0.981 +device: 0.912 +performance: 0.836 +kernel: 0.758 +debug: 0.634 +architecture: 0.413 +arm: 0.310 +network: 0.247 +register: 0.216 +ppc: 0.207 +boot: 0.204 +PID: 0.118 +vnc: 0.083 +semantic: 0.070 +permissions: 0.063 +virtual: 0.062 +socket: 0.047 +user-level: 0.044 +i386: 0.042 +x86: 0.024 +TCG: 0.024 +files: 0.022 +assembly: 0.022 +VMM: 0.022 +mistranslation: 0.020 +risc-v: 0.009 +peripherals: 0.003 +hypervisor: 0.003 +KVM: 0.001 + +Black screen and DTB errors while trying to emulate the kernel of the RaspiOS (based on Debian Bookworm) using the parameter -machine raspi4b diff --git a/results/classifier/118/graphic/2601 b/results/classifier/118/graphic/2601 new file mode 100644 index 000000000..a50ab657d --- /dev/null +++ b/results/classifier/118/graphic/2601 @@ -0,0 +1,66 @@ +graphic: 0.988 +architecture: 0.956 +TCG: 0.945 +arm: 0.941 +debug: 0.914 +assembly: 0.789 +performance: 0.788 +vnc: 0.759 +device: 0.756 +ppc: 0.707 +files: 0.645 +peripherals: 0.594 +hypervisor: 0.555 +risc-v: 0.530 +VMM: 0.504 +network: 0.482 +mistranslation: 0.406 +kernel: 0.380 +permissions: 0.379 +semantic: 0.358 +socket: 0.340 +user-level: 0.337 +PID: 0.331 +x86: 0.244 +boot: 0.235 +virtual: 0.229 +register: 0.227 +KVM: 0.107 +i386: 0.080 + +Executing LD1SB + MTE on Arm64 fails an assert +Description of problem: +I'm getting +``` +qemu-system-aarch64: ../tcg/tcg-op-gvec.c:91: simd_desc: Assertion `data == sextract32(data, 0, (32 - ((0 + 8) + 2)))' failed. +``` +This is caused by the upper bits of `data` being set to 1, which violates the condition. +Steps to reproduce: +1. build QEMU with assertions enabled (e.g., `configure --enable-debug-tcg`). +2. have a `LD1SB f{z25.d}, p3/z, [x14, x9]` (binary a5894dd9) instruction in the executed code. +3. enable mte +4. Let QEMU execute the ld1sb instruction. +Additional information: +{width=699 height=141} + +This issue happens because for ld1sb, nregs=0 in `sve.decode`: +``` +# SVE contiguous load (scalar plus scalar) +LD_zprr 1010010 .... ..... 010 ... ..... ..... @rprr_load_dt nreg=0 +``` +As a result, in do_mem_zpa is called with n_reg=0, which becomes mte_n inside do_mem_zpa. +Since mte_n==0, and mte_active, then +```c +desc = FIELD_DP32(desc, MTEDESC, SIZEM1, (mte_n << msz) - 1); +``` +sets (0) - 1 == -1 to the field, which also sets the upper bits of `desc`. +The `desc` with upper bits set to 1 is used to call: +```c +desc = simd_desc(vsz, vsz, zt | desc); +``` +Inside `simd_desc`, the last parameter is named `data` and it fails the assertion: +```c +tcg_debug_assert(data == sextract32(data, 0, SIMD_DATA_BITS)) +``` + +# diff --git a/results/classifier/118/graphic/2602 b/results/classifier/118/graphic/2602 new file mode 100644 index 000000000..c0288ee74 --- /dev/null +++ b/results/classifier/118/graphic/2602 @@ -0,0 +1,39 @@ +graphic: 0.991 +device: 0.929 +TCG: 0.712 +vnc: 0.700 +files: 0.640 +arm: 0.579 +risc-v: 0.572 +VMM: 0.561 +semantic: 0.550 +ppc: 0.498 +socket: 0.496 +debug: 0.481 +register: 0.477 +boot: 0.450 +network: 0.441 +PID: 0.383 +KVM: 0.289 +architecture: 0.260 +mistranslation: 0.246 +kernel: 0.223 +performance: 0.204 +permissions: 0.197 +user-level: 0.173 +x86: 0.113 +virtual: 0.073 +i386: 0.069 +peripherals: 0.066 +assembly: 0.036 +hypervisor: 0.011 + +Windows installer being signed with an expired certificate +Description of problem: +Digital Signature for setup is invalid +Steps to reproduce: +1. Downloaded the latest 64-bit windows installer +2. Right Click and select Digital Signature tab +3. Observe certificate shows valid dates are 12/8/2022 - 12/9/2023 +Additional information: +{width=621 height=393} diff --git a/results/classifier/118/graphic/2609 b/results/classifier/118/graphic/2609 new file mode 100644 index 000000000..1d571a234 --- /dev/null +++ b/results/classifier/118/graphic/2609 @@ -0,0 +1,41 @@ +graphic: 0.968 +device: 0.914 +semantic: 0.838 +architecture: 0.778 +performance: 0.751 +PID: 0.670 +register: 0.604 +user-level: 0.540 +ppc: 0.528 +peripherals: 0.526 +boot: 0.512 +debug: 0.506 +permissions: 0.469 +mistranslation: 0.408 +network: 0.401 +vnc: 0.398 +assembly: 0.377 +hypervisor: 0.376 +socket: 0.373 +VMM: 0.366 +kernel: 0.349 +risc-v: 0.344 +arm: 0.331 +x86: 0.316 +TCG: 0.307 +i386: 0.304 +files: 0.288 +virtual: 0.211 +KVM: 0.066 + +Blue screen in Windows XP +Description of problem: +When starting the installation of Windows XP when using a virtioblk device you immediately get a bluescreen: `STOP: 0x000000A5 (0x00000002, 0x8A1A6008, 0xE1018808, 0x8A1B7F00)`. I think this happens even before it loads the SATA drivers that are slipstreamed in the ISO. + +After a lot of Googling about this error 0x000000A5 I found some posts suggesting that changing the machine type from `q35` to `pc-q35-2.10` solves the issue. And it worked. Anything above 2.10 (for example 2.11) and the bluescreens return. + +So I always used this solution, but in QEMU 9.1.0 it warns that `pc-q35-2.10` will be removed soon. This would mean there is no way anymore to install XP to a SATA disk unattendly. +Steps to reproduce: +1. Use a virtioblk disk and SATA drivers +2. Start the Windows XP installer +3. Bluescreen will appear diff --git a/results/classifier/118/graphic/2616 b/results/classifier/118/graphic/2616 new file mode 100644 index 000000000..f8e4e19bf --- /dev/null +++ b/results/classifier/118/graphic/2616 @@ -0,0 +1,41 @@ +graphic: 0.881 +device: 0.729 +boot: 0.668 +performance: 0.661 +peripherals: 0.599 +architecture: 0.597 +files: 0.550 +permissions: 0.450 +ppc: 0.446 +hypervisor: 0.437 +risc-v: 0.408 +semantic: 0.402 +vnc: 0.390 +register: 0.340 +socket: 0.314 +kernel: 0.280 +PID: 0.257 +virtual: 0.249 +VMM: 0.225 +network: 0.219 +arm: 0.196 +assembly: 0.180 +user-level: 0.177 +debug: 0.176 +i386: 0.173 +x86: 0.168 +mistranslation: 0.127 +KVM: 0.029 +TCG: 0.020 + +crashout on any storage operation on SCO OpenServer 6 +Description of problem: +it's hard to exactly pinpoint what's wrong, but apparently it's a known issue. whenever i attempt to install or boot the OS, i get one of the two outcomes: with KVM it's a halt-and-catch-fire, getting stuck in an eternal loop of I/O errors and failed interrupts, with TCG at the very least the drivers get loaded and the installation disk is mounted, contrary to the emulated hard drive. connecting either drive to SCSI made HBA act like it's not there at all, and using the standard AHCI/IDE controllers leads to the result presented in the picture in one of the sections below, and, as mentioned earlier, this stage only happens with TCG. there's a 9:1 shot (on Q35, on PIIX3/PIIX4 it'll always either throw this exception or fail to initialise the CD-ROM) of it either screaming about a power failure right as it's ready to format the drive or it just installing. +Steps to reproduce: +1. download the old OpenServer 6 VM image/ISO from the SCO/Xinuos server. +2. attach it in your config. +3. go through initial setup stages (eg. entering a licence or deferring from such). +4. wait for the disk initialisation to begin. +Additional information: + + diff --git a/results/classifier/118/graphic/2621 b/results/classifier/118/graphic/2621 new file mode 100644 index 000000000..1cba4e2b5 --- /dev/null +++ b/results/classifier/118/graphic/2621 @@ -0,0 +1,45 @@ +graphic: 0.911 +device: 0.845 +performance: 0.613 +network: 0.610 +PID: 0.600 +VMM: 0.582 +hypervisor: 0.580 +architecture: 0.575 +virtual: 0.568 +semantic: 0.555 +ppc: 0.544 +kernel: 0.500 +risc-v: 0.484 +TCG: 0.474 +vnc: 0.421 +arm: 0.414 +permissions: 0.397 +register: 0.360 +debug: 0.357 +mistranslation: 0.357 +i386: 0.355 +files: 0.354 +socket: 0.352 +boot: 0.326 +peripherals: 0.324 +x86: 0.266 +KVM: 0.243 +user-level: 0.155 +assembly: 0.155 + +virtgpu does not return error for misconfigured virgl command +Description of problem: +When ```virgl_renderer_submit_cmd``` reports error, cmd->error should be set. Otherwise driver cannot know if there is error. +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu-virgl.c?ref_type=heads#L233 + +Probably 0x1200 (unspec) or 0x1205 (invalid param) should return as error. + + +If there is problem in cmd virgl freezes drawing window. +Steps to reproduce: +1. Send misformated command to virgl over vgpu device +2. +3. +Additional information: +Misformated 3d commands stops opengl's drawings. Without returning error we cannot know any error, hence we cannot reset vgpu. diff --git a/results/classifier/118/graphic/2642 b/results/classifier/118/graphic/2642 new file mode 100644 index 000000000..99475b106 --- /dev/null +++ b/results/classifier/118/graphic/2642 @@ -0,0 +1,35 @@ +graphic: 0.979 +architecture: 0.945 +semantic: 0.944 +socket: 0.933 +network: 0.906 +assembly: 0.894 +device: 0.888 +mistranslation: 0.886 +ppc: 0.883 +kernel: 0.879 +arm: 0.741 +performance: 0.649 +user-level: 0.634 +debug: 0.630 +register: 0.616 +hypervisor: 0.614 +KVM: 0.563 +PID: 0.517 +boot: 0.512 +risc-v: 0.501 +i386: 0.487 +permissions: 0.468 +files: 0.459 +vnc: 0.428 +x86: 0.420 +VMM: 0.419 +peripherals: 0.359 +virtual: 0.347 +TCG: 0.332 + +guest-set-time not supported +Description of problem: +guest-set-time is not supported un Ubuntu 24.04 guests. It still works on a Ubuntu 22.04 guest and on W10 and W11 guests + +feedback from the Ubuntu 24.04 guest: error: internal error: unable to execute QEMU agent command 'guest-set-time': this feature or command is not currently supported diff --git a/results/classifier/118/graphic/2645 b/results/classifier/118/graphic/2645 new file mode 100644 index 000000000..ff37d1fd8 --- /dev/null +++ b/results/classifier/118/graphic/2645 @@ -0,0 +1,53 @@ +graphic: 0.964 +performance: 0.846 +assembly: 0.819 +architecture: 0.739 +debug: 0.690 +PID: 0.682 +device: 0.680 +peripherals: 0.669 +semantic: 0.645 +x86: 0.610 +ppc: 0.529 +hypervisor: 0.510 +permissions: 0.476 +vnc: 0.432 +register: 0.401 +mistranslation: 0.398 +user-level: 0.387 +TCG: 0.377 +kernel: 0.320 +i386: 0.287 +VMM: 0.268 +boot: 0.243 +virtual: 0.238 +files: 0.230 +socket: 0.210 +risc-v: 0.196 +arm: 0.171 +network: 0.154 +KVM: 0.117 + +Failed shutdown during record with `ide-hd` disk. +Description of problem: +Running `shutdown -h now` on the guest with an `ide-hd` disk during a recording results in a long wait, followed by a BMDMA error. +Steps to reproduce: +1. Install Ubuntu Server guest OS and create disk snapshot +1. Reboot and log in: `qemu-system-x86_64 -hda ubuntu_snapshot.qcow2 -m 2g -net none -monitor stdio` +2. Take a snapshot: `savevm loggedin` +3. Start recording from VM snapshot: `./qemu/build/qemu-system-x86_64 -icount shift=auto,rr=record,rrfile=ubuntu_shutdown.bin -drive file=ubuntu_snapshot.qcow2,if=none,id=img-direct -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay -device ide-hd,drive=img-blkreplay -loadvm loggedin -net none -m 2g` +4. Run `shutdown -h now` in guest +5. Wait (~5-10 mins) +6. Observe BMDMA error (see below) +Additional information: +``` +ata1.00: exeption Emask 0x0 SAct 0.0 SErr 0.0 action 0x6 +ata1.00: BMDMA stat 0x5 +ata1.00: failed command: READ DMA +ata1.00: cmd c8/xx:xx:xx:xx:xx/xx:xx:xx:xx:xx/xx tag - dma 4096 in + res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation) +ata1.00: revalidation failed (errno=-2) +... +``` + +Note: Running the same command on a guest with a `virtio` disk results in further progress, but still does not shut down (stuck on `[ OK ] Stopped Create final runtime dir for shutdown pivot root.`) diff --git a/results/classifier/118/graphic/2669 b/results/classifier/118/graphic/2669 new file mode 100644 index 000000000..09654636b --- /dev/null +++ b/results/classifier/118/graphic/2669 @@ -0,0 +1,48 @@ +graphic: 0.871 +debug: 0.851 +device: 0.818 +architecture: 0.775 +virtual: 0.747 +vnc: 0.742 +semantic: 0.726 +hypervisor: 0.713 +performance: 0.683 +user-level: 0.681 +ppc: 0.677 +boot: 0.676 +kernel: 0.655 +register: 0.631 +mistranslation: 0.625 +permissions: 0.583 +VMM: 0.570 +socket: 0.557 +assembly: 0.524 +PID: 0.495 +network: 0.494 +KVM: 0.471 +risc-v: 0.435 +files: 0.434 +arm: 0.421 +x86: 0.396 +i386: 0.335 +peripherals: 0.318 +TCG: 0.277 + +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/118/graphic/2671 b/results/classifier/118/graphic/2671 new file mode 100644 index 000000000..1628430f0 --- /dev/null +++ b/results/classifier/118/graphic/2671 @@ -0,0 +1,47 @@ +graphic: 0.819 +device: 0.393 +boot: 0.197 +vnc: 0.170 +mistranslation: 0.168 +virtual: 0.140 +semantic: 0.115 +network: 0.073 +debug: 0.071 +i386: 0.066 +ppc: 0.063 +permissions: 0.063 +hypervisor: 0.051 +files: 0.050 +user-level: 0.050 +register: 0.049 +x86: 0.045 +PID: 0.032 +performance: 0.032 +socket: 0.031 +peripherals: 0.024 +architecture: 0.021 +risc-v: 0.019 +VMM: 0.018 +assembly: 0.017 +arm: 0.010 +TCG: 0.007 +kernel: 0.005 +KVM: 0.002 + +[Virtio-GPU Venus] I compiled virglrenderer with Venus support on 1.1.0,but could not boot QEMU with virtio-gpu Venus +Description of problem: +When I tried to use virtio-gpu-gl with venus=true like the template,it shows: +{width=1251 height=75} +But I have already compile virglrenderer using: + meson setup build \ + -Dvenus=true \ + -Drender-server=true \ + -Drender-server-worker=thread \ + -Dbuildtype=release \ + -Dprefix=${INSTDIR} + +and run QEMU with designated environment variables,but it still cannot boot,but if I use QEMU-8.0 with Venus-v17 patch and it works😭 +Steps to reproduce: +Just use "-device virtio-gpu-gl,hostmem=4G,blob=true,venus=true" and it will show the problem +Additional information: +No diff --git a/results/classifier/118/graphic/2672 b/results/classifier/118/graphic/2672 new file mode 100644 index 000000000..fad114093 --- /dev/null +++ b/results/classifier/118/graphic/2672 @@ -0,0 +1,50 @@ +graphic: 0.901 +device: 0.714 +performance: 0.602 +architecture: 0.467 +kernel: 0.462 +vnc: 0.423 +ppc: 0.418 +permissions: 0.384 +files: 0.361 +risc-v: 0.355 +arm: 0.327 +socket: 0.247 +boot: 0.240 +peripherals: 0.227 +mistranslation: 0.222 +PID: 0.222 +semantic: 0.216 +network: 0.205 +assembly: 0.203 +x86: 0.201 +debug: 0.187 +VMM: 0.127 +register: 0.125 +TCG: 0.124 +i386: 0.114 +user-level: 0.106 +virtual: 0.057 +KVM: 0.040 +hypervisor: 0.005 + +Skipping a jal instruction in riscv64 baremetal emulation +Description of problem: +The binary contains an illegal instruction after a jal. Normally the jal should be taken but the illegal instructi[aia_tests2.elf](/uploads/b8b646b01d7bcc15b51c36ddbffacac7/aia_tests2.elf)on next to the jal is executed generating and illegal instruction exception: + +``` +0x80006070: 00200513 addi a0,zero,2 +0x80006074: 89cff0ef jal ra,-3940 # 0x80005110 + +---------------- +IN: _Z15int_switch_modehh +0x80006078: 0000 illegal + +---------------- +IN: mtvec_table +0x8000e600: 64d0406f j 20044 # 0x8001344c +``` +Steps to reproduce: +1. Execute the same binary with QEMU. +Additional information: + diff --git a/results/classifier/118/graphic/2673 b/results/classifier/118/graphic/2673 new file mode 100644 index 000000000..efa8d93db --- /dev/null +++ b/results/classifier/118/graphic/2673 @@ -0,0 +1,35 @@ +graphic: 0.914 +device: 0.704 +semantic: 0.624 +socket: 0.495 +performance: 0.446 +risc-v: 0.417 +network: 0.380 +register: 0.351 +mistranslation: 0.339 +files: 0.318 +permissions: 0.310 +x86: 0.288 +architecture: 0.273 +i386: 0.265 +hypervisor: 0.244 +PID: 0.163 +vnc: 0.141 +arm: 0.136 +KVM: 0.135 +peripherals: 0.130 +TCG: 0.116 +boot: 0.092 +debug: 0.092 +VMM: 0.084 +kernel: 0.070 +virtual: 0.060 +ppc: 0.044 +assembly: 0.032 +user-level: 0.021 + +qemu-system-riscv32 does not pass official riscv-tests +Description of problem: +I run riscv-tests using the above command and find qemu raises Illegalinstruction when `sret` in the machine mode.Therefore qemu cannot pass the rv32ui-v-and test. +Additional information: +The tests https://github.com/riscv-software-src/riscv-tests diff --git a/results/classifier/118/graphic/2674 b/results/classifier/118/graphic/2674 new file mode 100644 index 000000000..19c5e8d8e --- /dev/null +++ b/results/classifier/118/graphic/2674 @@ -0,0 +1,54 @@ +graphic: 0.984 +boot: 0.874 +architecture: 0.832 +device: 0.782 +semantic: 0.681 +ppc: 0.661 +socket: 0.616 +performance: 0.612 +permissions: 0.525 +user-level: 0.519 +risc-v: 0.513 +vnc: 0.469 +PID: 0.467 +debug: 0.452 +files: 0.447 +arm: 0.443 +TCG: 0.418 +mistranslation: 0.405 +register: 0.361 +hypervisor: 0.306 +kernel: 0.286 +VMM: 0.285 +peripherals: 0.229 +virtual: 0.217 +network: 0.186 +x86: 0.173 +i386: 0.115 +KVM: 0.104 +assembly: 0.097 + +NextSTEP 3.3 for Sparc graphical glitches +Description of problem: +It installs/boot by using complex boot syntax and taskset -c 0 under Linux + +see end of https://gitlab.com/qemu-project/qemu/-/issues/2620#note_2207999780 + +But after it installs I see some gfx corruption +Steps to reproduce: +1. install NEXTSTEP 3.3 for RISC computers +2. Boot to desktop (may need ctrl-c to skip some services at startup) +3. Select Info and watch for Workspace Manager info window to appear. +4. Move this window to the right - it corrupts! +Additional information: +Bug also exist if I boot qemu with -g 1024x768x24 + +Moving window vertically (up/down) does not corrupt it +Moving any window around corrupt it. + +Resizing and scrolling inside say Terminal emulators work. + +There was 86Box issue around one FPU instruction that looked a bit like this, +is there way to check fpu emulation? + + diff --git a/results/classifier/118/graphic/2675 b/results/classifier/118/graphic/2675 new file mode 100644 index 000000000..b70bedd22 --- /dev/null +++ b/results/classifier/118/graphic/2675 @@ -0,0 +1,41 @@ +graphic: 0.903 +device: 0.883 +debug: 0.833 +semantic: 0.582 +performance: 0.545 +PID: 0.431 +register: 0.429 +vnc: 0.427 +i386: 0.365 +mistranslation: 0.311 +socket: 0.306 +architecture: 0.305 +x86: 0.285 +boot: 0.220 +files: 0.215 +permissions: 0.213 +network: 0.211 +ppc: 0.203 +TCG: 0.171 +peripherals: 0.111 +user-level: 0.100 +risc-v: 0.099 +hypervisor: 0.086 +assembly: 0.079 +VMM: 0.076 +virtual: 0.073 +arm: 0.042 +kernel: 0.019 +KVM: 0.001 + +q800 machine is broken when compiling with --enable-cfi +Description of problem: +When compiling QEMU that is configured like this: +``` + .../configure --target-list=m68k-softmmu --enable-cfi --cc=clang +``` +the q800 machine crashes with an illegal exception on the host very early, somewhere during q800_machine_init() +Steps to reproduce: +1. .../configure --target-list=m68k-softmmu --enable-cfi --cc=clang +2. make qemu-system-m68k +3. ./qemu-system-m68k -M q800 diff --git a/results/classifier/118/graphic/2680 b/results/classifier/118/graphic/2680 new file mode 100644 index 000000000..7f39c6838 --- /dev/null +++ b/results/classifier/118/graphic/2680 @@ -0,0 +1,44 @@ +graphic: 0.933 +device: 0.875 +performance: 0.822 +boot: 0.636 +architecture: 0.590 +semantic: 0.589 +mistranslation: 0.566 +arm: 0.559 +assembly: 0.553 +permissions: 0.550 +peripherals: 0.488 +vnc: 0.468 +debug: 0.465 +risc-v: 0.462 +socket: 0.455 +PID: 0.455 +ppc: 0.421 +kernel: 0.399 +register: 0.357 +i386: 0.255 +user-level: 0.243 +hypervisor: 0.235 +KVM: 0.165 +VMM: 0.163 +virtual: 0.132 +TCG: 0.130 +x86: 0.129 +files: 0.116 +network: 0.105 + +GTK accelerators (including releasing input grab) don't work in keyboard layouts that utilize AltGr on Windows +Description of problem: +With a non-QWERTY (in my case, Colemak) layout active, it's not possible to ungrab input from the window using the Ctrl-Alt-G. The key combination is simply ignored, whether the G is typed using the physical key G on the keyboard or the one where it would be mapped by the keyboard layout (physical T key for Colemak). Thankfully, because of #2225, the mouse cursor isn't actually captured, which allows me to move the mouse outside the window and close QEMU from the taskbar instead. + +Temporarily switching back to a QWERTY layout before the grab happens allows input to be released using the key combo. However this needs to be done before the capture as otherwise QEMU will simply intercept any shortcuts to toggle the layout. + +I suspect there's some mismatch between the input grabbing code and the GTK UI, where one is using the keyboard scancode to determine when to forward the key, but the GTK UI then uses the mapped letter from the layout and fails to activate the shortcut. +Steps to reproduce: +1. Configure a non-QWERTY layout (such as Dvorak or Colemak) in the system settings +1. Launch QEMU (it's not necessary to load any guest, booting the BIOS is fine) +2. Click on the window which will automatically capture input +3. Try to release using the Ctrl-Shift-G shortcut (in either layout), which should be ignored +Additional information: + diff --git a/results/classifier/118/graphic/2687 b/results/classifier/118/graphic/2687 new file mode 100644 index 000000000..44e490eb2 --- /dev/null +++ b/results/classifier/118/graphic/2687 @@ -0,0 +1,79 @@ +graphic: 0.914 +x86: 0.864 +performance: 0.782 +device: 0.642 +architecture: 0.580 +socket: 0.576 +ppc: 0.558 +register: 0.538 +semantic: 0.534 +debug: 0.522 +user-level: 0.504 +PID: 0.449 +virtual: 0.415 +mistranslation: 0.379 +vnc: 0.300 +arm: 0.291 +network: 0.285 +risc-v: 0.281 +TCG: 0.267 +i386: 0.249 +hypervisor: 0.245 +assembly: 0.240 +kernel: 0.201 +VMM: 0.198 +peripherals: 0.189 +files: 0.147 +permissions: 0.136 +boot: 0.131 +KVM: 0.073 + +regression in qtest clock_set/clock_step +Description of problem: +As of QEMU 9.0 the script included below would increment the time via qtest, but it is now broken and time doesn't seem to be updated. I do note that the QEMU sources use clock_step extensively via qtest_clock_step, but nothing seems to be using the return value so maybe that's why it hasn't been noticed? + +It seems to have been broken in bc02be4508d8753d1f6071b77d10f4661587df6f which was trying to prevent some deadlock. You can prove that this breaks it by setting a breakpoint in `qemu_virtual_clock_set_ns` -- it never gets called. +Steps to reproduce: +Run this python script from your QEMU build directory: + +```python +#!/usr/bin/env python3 + +import subprocess +import socket +import typing + +qemu_path = "./qemu-system-x86_64" + + +def main(): + s1, s2 = socket.socketpair() + + qemu = subprocess.Popen( + [ + qemu_path, + "-S", + "-display", + "none", + "-chardev", f"socket,id=qtest,fd={s1.fileno()},nodelay=on", + "-qtest", "chardev:qtest", + "-qtest-log", "/dev/fd/2", + "-accel", "qtest", + ], + pass_fds=[s1.fileno()], + ) + + try: + + fp = s2.makefile("rw", buffering=1) + + fp.write(f"clock_set 1234\n") + result = fp.readline()[:-1].split(" ") + assert result == ["OK", "1234"], f"Unexpected result: {result}" + finally: + qemu.kill() + + +if __name__ == "__main__": + main() +``` diff --git a/results/classifier/118/graphic/2690 b/results/classifier/118/graphic/2690 new file mode 100644 index 000000000..d1a7e9b2e --- /dev/null +++ b/results/classifier/118/graphic/2690 @@ -0,0 +1,50 @@ +graphic: 0.852 +semantic: 0.814 +device: 0.722 +performance: 0.685 +hypervisor: 0.658 +x86: 0.577 +socket: 0.553 +network: 0.550 +vnc: 0.512 +mistranslation: 0.495 +virtual: 0.478 +i386: 0.468 +architecture: 0.462 +debug: 0.438 +kernel: 0.415 +risc-v: 0.393 +ppc: 0.381 +user-level: 0.374 +VMM: 0.371 +arm: 0.365 +register: 0.358 +TCG: 0.341 +boot: 0.341 +PID: 0.333 +peripherals: 0.316 +permissions: 0.227 +KVM: 0.139 +assembly: 0.137 +files: 0.132 + +"Guest says index 40947 is available" +Description of problem: +As discussed [here](https://github.com/danobi/vmtest/issues/96) I have been running several instances of QEMU in parallel at `SCHED_IDLE`, and I've been getting QGA setup failures. +Steps to reproduce: +1. Install [vmtest](https://github.com/danobi/vmtest) +2. Run lots of copies of the command in the [github issues](https://github.com/danobi/vmtest/issues/96) via `chrt --idle 0`. +3. Unclear if this is the cause, but then I use the computer in the meantime so probably starve the `SCHED_IDLE` QEMU threads running from 2. + +This leads to failures to connect to the guest agent and then at the end I see this: + +``` +Guest says index 40947 is available + qemu-system-x86_64: Guest says index 40947 is available + qemu-system-x86_64: Guest says index 40947 is available +``` + + +The developer of vmtest seemed to think this may be of interest to QEMU developers based on the tone of the [comment they found](https://github.com/danobi/vmtest/issues/96#issuecomment-2483860554) in the QEMU code. + +I've now installed QEMU from Git master so I can report back whether the bug still appeared. diff --git a/results/classifier/118/graphic/2712 b/results/classifier/118/graphic/2712 new file mode 100644 index 000000000..f46d8e6ff --- /dev/null +++ b/results/classifier/118/graphic/2712 @@ -0,0 +1,41 @@ +graphic: 0.838 +device: 0.800 +boot: 0.755 +KVM: 0.652 +semantic: 0.633 +risc-v: 0.371 +hypervisor: 0.368 +performance: 0.368 +vnc: 0.367 +PID: 0.325 +register: 0.306 +debug: 0.298 +architecture: 0.298 +mistranslation: 0.289 +ppc: 0.280 +virtual: 0.205 +user-level: 0.203 +arm: 0.198 +i386: 0.196 +permissions: 0.168 +TCG: 0.159 +VMM: 0.156 +x86: 0.148 +socket: 0.146 +network: 0.086 +assembly: 0.070 +peripherals: 0.037 +kernel: 0.035 +files: 0.035 + +Windows VM doesn't boot on QEMU KVM when hypervisor is disabled in Linux 6.12 +Description of problem: +Windows VM doesn't boot on QEMU KVM when hypervisor is disabled in Linux 6.12. QEMU uses 100% CPU core usage and nothing happens. + +It boots properly in Linux 6.11.10. I don't know if it's a kernel bug or QEMU needs some changes to work with the new kernel correctly. +Steps to reproduce: +1. Boot Windows 10 or 11 (can be installation ISO form official website) with KVM, but set "hypervisor=off" CPU parameter. +2. Wait. +3. Nothing happens - doesn't boot. +Additional information: +Nothing is displayed in console. diff --git a/results/classifier/118/graphic/2722 b/results/classifier/118/graphic/2722 new file mode 100644 index 000000000..e6ad056ad --- /dev/null +++ b/results/classifier/118/graphic/2722 @@ -0,0 +1,78 @@ +graphic: 0.884 +user-level: 0.884 +virtual: 0.880 +peripherals: 0.871 +semantic: 0.869 +vnc: 0.867 +permissions: 0.866 +risc-v: 0.860 +ppc: 0.858 +arm: 0.855 +device: 0.846 +debug: 0.841 +hypervisor: 0.840 +kernel: 0.835 +boot: 0.835 +register: 0.831 +PID: 0.829 +performance: 0.826 +VMM: 0.798 +architecture: 0.798 +assembly: 0.786 +socket: 0.782 +TCG: 0.780 +network: 0.775 +files: 0.774 +mistranslation: 0.762 +KVM: 0.757 +x86: 0.662 +i386: 0.597 + +TLB Invalidation time out on i915 SR-IOV passthrough +Description of problem: +Hello, + +I tried to use SR-IOV on i915 driver freshly available on the [LTS intel kernel](https://github.com/intel/linux-intel-lts) with this [kernel version ](https://github.com/intel/linux-intel-lts/tree/lts-v6.6.34-linux-240626T131354Z) for pci passthrough purpose. +After setting up SR-IOV (kernel compilation, kernel cmdline, vfio-pci driver attribution to the new pci..) + I've got my two new pci. + +``` +00:02.0 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c) +DeviceName: Onboard IGD + +Subsystem: Hewlett-Packard Company Alder Lake-P Integrated Graphics Controller +Kernel driver in use: i915 + +00:02.1 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c) +Subsystem: Hewlett-Packard Company Alder Lake-P Integrated Graphics Controller +Kernel driver in use: vfio-pci + +00:02.2 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c) +Subsystem: Hewlett-Packard Company Alder Lake-P Integrated Graphics Controller +Kernel driver in use: vfio-pci +``` +I gave one of those pci to my VM with this qemu cmdline: +``` +-cpu host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-passthrough,hv-vendor-id=IrisXE +... +-device vfio-pci-nohotplug,host=0000:00:02.1,id=hostdev0,bus=pci.4,addr=0x0 +``` +Sometimes it working properly when I start the qemu cmdline but most of the time I've got those kernel errors and a GPU hang: +``` + kernel [ 2252.208134] i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679 + kernel [ 2252.208134] i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679 + kernel i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679 + kernel i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 9679 + .... + kernel Fence expiration time out i915-0000:00:02.0:renderThread22381:6e0! + kernel i915 0000:00:02.0: [drm] GT0: GuC firmware i915/adlp_guc_70.bin version 70.13.1 + kernel i915 0000:00:02.0: [drm] GT0: HuC firmware i915/tgl_huc.bin version 7.9.3 + kernel i915 0000:00:02.0: [drm] GT0: HuC: authenticated for all workloads + kernel i915 0000:00:02.0: [drm] GT0: GUC: submission enabled + kernel i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled + kernel [ 2730.991019] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:85dfbfff, in renderThread [22381] + kernel [ 2730.991084] i915 0000:00:02.0: [drm] renderThread22381 context reset due to GPU hang +``` +It mostly appears when Qemu is starting.. + +Any help would be appreciate, thanks a lot diff --git a/results/classifier/118/graphic/2723 b/results/classifier/118/graphic/2723 new file mode 100644 index 000000000..9d900ad83 --- /dev/null +++ b/results/classifier/118/graphic/2723 @@ -0,0 +1,53 @@ +graphic: 0.955 +semantic: 0.800 +architecture: 0.743 +vnc: 0.705 +boot: 0.662 +files: 0.569 +device: 0.555 +x86: 0.535 +ppc: 0.500 +user-level: 0.457 +socket: 0.429 +mistranslation: 0.417 +i386: 0.392 +VMM: 0.375 +virtual: 0.332 +PID: 0.330 +network: 0.271 +register: 0.262 +risc-v: 0.245 +performance: 0.235 +debug: 0.228 +KVM: 0.217 +kernel: 0.211 +TCG: 0.171 +permissions: 0.150 +hypervisor: 0.121 +arm: 0.104 +peripherals: 0.096 +assembly: 0.059 + +qemu-system-sparc: nesqemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled +Description of problem: +It boots into the BIOS. I connect to the monitor on port 4444, and send "sendkey stop-a", and then in the main window (VNC session) I enter "boot disk1:d". It starts to load vmunix, and then crashes with:- + ``` +nesqemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled, Error state +pc: f00053dc npc: f00053e0 +%g0-7: 00000000 f00ee048 00000000 ffef0000 ffef9b6c f00e1000 00000000 ffefebc4 +%o0-7: 00008000 00008000 000000e0 feff8008 00001ff0 00000068 f00d7490 f0005c98 +%l0-7: 04800fc1 f0005d14 f0005d18 00000002 0000010f 00000002 00000007 f00d6f50 +%i0-7: 00008000 00008000 00000005 feff8008 00000000 00000000 f00d6ff8 f0005c98 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +psr: 04000fc1 (icc: ---- SPE: SP-) wim: 00000002 +fsr: 00080000 y: 00000000 + +Aborted (core dumped) + ``` +Additional information: +md5sums (both files can be found online) +ede0690b3cb3d2abb6bddd8136912106 Solaris1_1_2.iso +6364e9a6f5368e2ecc4e9c1d915a93ae ss5.bin diff --git a/results/classifier/118/graphic/2728 b/results/classifier/118/graphic/2728 new file mode 100644 index 000000000..5f00b25f8 --- /dev/null +++ b/results/classifier/118/graphic/2728 @@ -0,0 +1,45 @@ +graphic: 0.876 +x86: 0.723 +virtual: 0.669 +device: 0.610 +VMM: 0.457 +performance: 0.383 +socket: 0.375 +semantic: 0.346 +boot: 0.287 +hypervisor: 0.273 +permissions: 0.257 +PID: 0.234 +register: 0.193 +architecture: 0.189 +risc-v: 0.176 +vnc: 0.163 +network: 0.160 +ppc: 0.151 +debug: 0.123 +mistranslation: 0.120 +assembly: 0.112 +arm: 0.093 +peripherals: 0.092 +files: 0.088 +i386: 0.071 +kernel: 0.057 +user-level: 0.055 +TCG: 0.051 +KVM: 0.020 + +QEMU/Virt-Manager + QXL 4k Resolution + Win 10 and Win 11 Guest freeze +Description of problem: +I use two 4k displays in my VM with 150% display scaling. After a random amount of time the screen locks up. It can lock up before i can log in or it can wait a few minutes into using it before it stops responding. It still pings but is unresponsive via the display. I've tried several different builds of the guest drivers but that did not work, the only solution has been to revert to QEMU v9.0.2-1. +Steps to reproduce: +1.Create new x86 VM using QXl video, Install Windows 10 or Windows 11 and latest guest drivers from spice and fedora +2.Open with virt viewer and resize both screens to 3840 x 2160 or use autosize +3.Set display scaling to 150% +4.Lockup occurs at some point after that but not more than 5 minutes. +Additional information: +There seems to be a similar bug here:https://gitlab.com/qemu-project/qemu/-/issues/1628#note_214460662 +also a debian forum post here: https://forums.debian.net/viewtopic.php?t=160631 +QEMU v9.0.2-1 does not have this problem, eliminating the guest drivers as a culprit + + +/label ~"kind::Bug" diff --git a/results/classifier/118/graphic/2729 b/results/classifier/118/graphic/2729 new file mode 100644 index 000000000..f650c154b --- /dev/null +++ b/results/classifier/118/graphic/2729 @@ -0,0 +1,104 @@ +register: 0.982 +graphic: 0.977 +architecture: 0.956 +debug: 0.952 +kernel: 0.939 +files: 0.924 +performance: 0.908 +user-level: 0.872 +ppc: 0.871 +peripherals: 0.867 +assembly: 0.847 +semantic: 0.828 +device: 0.774 +PID: 0.766 +mistranslation: 0.755 +vnc: 0.743 +socket: 0.729 +boot: 0.710 +network: 0.709 +arm: 0.703 +hypervisor: 0.701 +risc-v: 0.694 +TCG: 0.685 +VMM: 0.677 +permissions: 0.655 +KVM: 0.621 +x86: 0.567 +virtual: 0.552 +i386: 0.532 + +qemu-system-aarch64 -M raspi4b -- no valid DTB provided in x0 register +Description of problem: +When starting `qemu-system-aarch64 -M raspi4b`, no valid DTB is provided in x0. +Steps to reproduce: +Make a simple binary to loop forever + +``` +$ cat loop.c +void _start(void) +{ + for(;;) + ; +} +$ aarch64-linux-gnu-gcc loop.c -nostdlib +$ aarch64-linux-gnu-objcopy -O binary a.out loop.bin +``` + +Start qemu for debugging and start gdb + +``` +$ qemu-system-aarch64 -S -s -M raspi4b -kernel loop.bin +# in another terminal +$ aarch64-linux-gnu-gdb +(gdb) target remote :1234 +Remote debugging using :1234 +warning: No executable has been specified and target does not support +determining executable automatically. Try using the "file" command. +0x0000000000000000 in ?? () +(gdb) watch *$x0 +Watchpoint 3: *$x0 +(gdb) watch $x0 +Watchpoint 4: $x0 +(gdb) x/2x$x0 +0x0: 0x580000c0 0xaa1f03e1 +(gdb) si + +Thread 1 hit Watchpoint 3: *$x0 + +Old value = 1476395200 +New value = 5 + +Thread 1 hit Watchpoint 4: $x0 + +Old value = 0 +New value = 256 +0x0000000000000004 in ?? () +(gdb) x/2x$x0 +0x100: 0x00000005 0x54410001 +(gdb) si +0x0000000000000008 in ?? () +(gdb) si +0x000000000000000c in ?? () +(gdb) si +0x000000000000000c in ?? () +(gdb) si +0x0000000000000010 in ?? () +(gdb) si +0x0000000000000014 in ?? () +(gdb) si +0x0000000000080000 in ?? () +(gdb) si +0x0000000000000200 in ?? () +(gdb) si +0x0000000000000200 in ?? () +(gdb) si +0x0000000000000200 in ?? () +(gdb) si +0x0000000000000200 in ?? () +(gdb) x/2x$x0 +0x100: 0x00000005 0x54410001 +(gdb) +``` + +Note that at no time is a valid DTB provided in x0. I expected to see the DTB magic 0xd00dfeed (or 0xedfe0dd0) at the memory pointed to by x0 diff --git a/results/classifier/118/graphic/2730 b/results/classifier/118/graphic/2730 new file mode 100644 index 000000000..92a34093d --- /dev/null +++ b/results/classifier/118/graphic/2730 @@ -0,0 +1,40 @@ +graphic: 0.906 +device: 0.787 +vnc: 0.738 +risc-v: 0.511 +network: 0.497 +ppc: 0.478 +socket: 0.466 +kernel: 0.421 +assembly: 0.411 +semantic: 0.353 +mistranslation: 0.340 +debug: 0.339 +arm: 0.317 +TCG: 0.304 +VMM: 0.301 +files: 0.260 +boot: 0.244 +hypervisor: 0.239 +register: 0.231 +KVM: 0.227 +x86: 0.222 +performance: 0.218 +peripherals: 0.216 +i386: 0.202 +PID: 0.196 +architecture: 0.181 +virtual: 0.124 +user-level: 0.111 +permissions: 0.074 + +riscv Calculation error！ +Steps to reproduce: +The following command will produce an error output + +```asm + lui s0, 0x80000 + lw a1, -48(s0) +``` +The value of a1 becomes 0xffffffff + diff --git a/results/classifier/118/graphic/2736 b/results/classifier/118/graphic/2736 new file mode 100644 index 000000000..71f89b545 --- /dev/null +++ b/results/classifier/118/graphic/2736 @@ -0,0 +1,40 @@ +graphic: 0.872 +device: 0.774 +vnc: 0.595 +debug: 0.573 +performance: 0.536 +network: 0.463 +semantic: 0.401 +socket: 0.389 +ppc: 0.381 +architecture: 0.379 +files: 0.365 +i386: 0.336 +TCG: 0.318 +PID: 0.316 +permissions: 0.306 +VMM: 0.298 +boot: 0.275 +x86: 0.248 +kernel: 0.236 +hypervisor: 0.235 +register: 0.219 +risc-v: 0.182 +KVM: 0.162 +arm: 0.158 +peripherals: 0.120 +virtual: 0.120 +mistranslation: 0.115 +user-level: 0.095 +assembly: 0.048 + +assert_fail in vmstate_load_state (icount related) +Description of problem: +qemu crashes with an assert failure. +Steps to reproduce: +- Run qemu-system-sparc with "-i count auto -rtc clock=vm" + - Create a snapshot. Exit qemu. + - Run qemu-system-sparc without "-i count auto -rtc clock-vm" + - Try to load the snapshot via the monitor +Additional information: +[gdb.out](/uploads/d08539ce9eb6b599918513e279f13453/gdb.out) diff --git a/results/classifier/118/graphic/2748 b/results/classifier/118/graphic/2748 new file mode 100644 index 000000000..d77d1d30c --- /dev/null +++ b/results/classifier/118/graphic/2748 @@ -0,0 +1,280 @@ +graphic: 0.917 +permissions: 0.882 +mistranslation: 0.863 +risc-v: 0.862 +semantic: 0.857 +register: 0.851 +device: 0.842 +arm: 0.841 +user-level: 0.839 +performance: 0.836 +debug: 0.829 +assembly: 0.827 +files: 0.826 +boot: 0.823 +virtual: 0.821 +TCG: 0.819 +socket: 0.816 +peripherals: 0.814 +architecture: 0.811 +PID: 0.803 +kernel: 0.803 +x86: 0.781 +ppc: 0.773 +network: 0.771 +vnc: 0.738 +hypervisor: 0.716 +KVM: 0.712 +i386: 0.706 +VMM: 0.704 + +Windows specific main loop deadlock when using serial pipe communication +Description of problem: +Attaching WinDBG (or for that matter, any other serial end that sends data quickly enough) causes QEMU to deadlock. +Steps to reproduce: +1. Fire up QEMU with Windows (serial debugging enable) +2. Restart +3. At boot time, plug-in host WinDBG +Additional information: +WinDBG QEMU stacktrace +``` +0:020> g +(34c4.2330): Control-C exception - code 40010005 (first chance) +First chance exceptions are reported before any exception handling. +This exception may be expected and handled. +KERNELBASE!CtrlRoutine+0x1be: +00007ffe`82ace6ce 0f1f440000 nop dword ptr [rax+rax] +0:019> g +(34c4.3b3c): Break instruction exception - code 80000003 (first chance) +ntdll!DbgBreakPoint: +00007ffe`850d4090 cc int 3 +0:017> ~*k + + 0 Id: 34c4.28b8 Suspend: 1 Teb: 0000009f`a24ac000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a27f7388 00007ffe`829e6656 ntdll!NtCreateEvent+0x14 +0000009f`a27f7390 00007ff7`38abcbd6 KERNELBASE!PeekNamedPipe+0xa6 +0000009f`a27f7460 00007ff7`38bb8f11 qemu_system_x86_64!win_chr_pipe_poll+0x84 +0000009f`a27f74d0 00007ff7`38bb93fb qemu_system_x86_64!os_host_main_loop_wait+0x133 +0000009f`a27ffba0 00007ff7`38686c45 qemu_system_x86_64!main_loop_wait+0xce +0000009f`a27ffc00 00007ff7`38ac2f14 qemu_system_x86_64!qemu_main_loop+0x2b +0000009f`a27ffc40 00007ff7`38ac2f52 qemu_system_x86_64!qemu_default_main+0x14 +0000009f`a27ffc80 00007ff7`38bdeede qemu_system_x86_64!SDL_main+0x26 +0000009f`a27ffcb0 00007ff7`3838140a qemu_system_x86_64!__mingw_enum_import_library_names+0x24e +0000009f`a27ffd30 00007ff7`383814f6 qemu_system_x86_64!__tmainCRTStartup+0xea +0000009f`a27ffd70 00007ffe`83ca259d qemu_system_x86_64!mainCRTStartup+0x16 +0000009f`a27ffda0 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a27ffdd0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 1 Id: 34c4.2738 Suspend: 1 Teb: 0000009f`a24ae000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a29ffaa8 00007ffe`8506586e ntdll!NtWaitForWorkViaWorkerFactory+0x14 +0000009f`a29ffab0 00007ffe`83ca259d ntdll!TppWorkerThread+0x2ee +0000009f`a29ffd90 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a29ffdc0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 2 Id: 34c4.35e4 Suspend: 1 Teb: 0000009f`a24b0000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a2bffa88 00007ffe`8506586e ntdll!NtWaitForWorkViaWorkerFactory+0x14 +0000009f`a2bffa90 00007ffe`83ca259d ntdll!TppWorkerThread+0x2ee +0000009f`a2bffd70 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a2bffda0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 3 Id: 34c4.24f0 Suspend: 1 Teb: 0000009f`a24b2000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a2dff838 00007ffe`8506586e ntdll!NtWaitForWorkViaWorkerFactory+0x14 +0000009f`a2dff840 00007ffe`83ca259d ntdll!TppWorkerThread+0x2ee +0000009f`a2dffb20 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a2dffb50 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 4 Id: 34c4.2898 Suspend: 1 Teb: 0000009f`a24b4000 Unfrozen "pool" +Child-SP RetAddr Call Site +0000009f`a2fffb58 00007ffe`850997db ntdll!NtWaitForAlertByThreadId+0x14 +0000009f`a2fffb60 00007ffe`829df2e9 ntdll!RtlSleepConditionVariableSRW+0x13b +0000009f`a2fffbe0 00007ffd`cb1c6903 KERNELBASE!SleepConditionVariableSRW+0x29 +0000009f`a2fffc20 00007ffd`cb235399 libglib_2_0_0!g_byte_array_sort_with_data+0x143 +0000009f`a2fffc80 00007ffd`cb234a41 libglib_2_0_0!g_get_num_processors+0x2c9 +0000009f`a2fffce0 00007ffd`cb2696f7 libglib_2_0_0!g_test_get_path+0x51 +0000009f`a2fffd20 00007ffe`8424e634 libglib_2_0_0!g_private_replace+0x117 +0000009f`a2fffd50 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`a2fffd80 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`a2fffdb0 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a2fffde0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 5 Id: 34c4.2ed8 Suspend: 1 Teb: 0000009f`a24b6000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a31ff9b8 00007ffe`829a9cee ntdll!NtWaitForSingleObject+0x14 +0000009f`a31ff9c0 00007ff7`38b9f99f KERNELBASE!WaitForSingleObjectEx+0x8e +0000009f`a31ffa60 00007ff7`38baba83 qemu_system_x86_64!qemu_event_wait+0xe3 +0000009f`a31ffac0 00007ff7`38b9faf2 qemu_system_x86_64!call_rcu_thread+0x6c +0000009f`a31ffb00 00007ffe`8424e634 qemu_system_x86_64!win32_start_routine+0x4e +0000009f`a31ffb50 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`a31ffb80 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`a31ffbb0 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a31ffbe0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 6 Id: 34c4.2980 Suspend: 1 Teb: 0000009f`a24b8000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a35ff888 00007ffe`82dc54a7 win32u!NtUserMsgWaitForMultipleObjectsEx+0x14 +0000009f`a35ff890 00007ffe`71373c70 USER32!MsgWaitForMultipleObjects+0x57 +0000009f`a35ff8d0 00007ffe`71373bc9 gdiplus!BackgroundThreadProc+0x70 +0000009f`a35ff940 00007ffe`83ca259d gdiplus!DllRefCountSafeThreadThunk+0x29 +0000009f`a35ff970 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a35ff9a0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 7 Id: 34c4.3880 Suspend: 1 Teb: 0000009f`a24ba000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a37ff808 00007ffe`829c6849 ntdll!NtWaitForMultipleObjects+0x14 +0000009f`a37ff810 00007ffe`837707ad KERNELBASE!WaitForMultipleObjectsEx+0xe9 +0000009f`a37ffaf0 00007ffe`8377061a combase!WaitCoalesced+0xa9 +0000009f`a37ffd90 00007ffe`8377040f combase!CROIDTable::WorkerThreadLoop+0x5a +0000009f`a37ffde0 00007ffe`83770829 combase!CRpcThread::WorkerLoop+0x57 +0000009f`a37ffe60 00007ffe`83ca259d combase!CRpcThreadCache::RpcWorkerThreadEntry+0x29 +0000009f`a37ffe90 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a37ffec0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 8 Id: 34c4.1bd0 Suspend: 1 Teb: 0000009f`a24bc000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a39ffaa8 00007ffe`8506586e ntdll!NtWaitForWorkViaWorkerFactory+0x14 +0000009f`a39ffab0 00007ffe`83ca259d ntdll!TppWorkerThread+0x2ee +0000009f`a39ffd90 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a39ffdc0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 9 Id: 34c4.20fc Suspend: 1 Teb: 0000009f`a24be000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a3bffa78 00007ffe`8506586e ntdll!NtWaitForWorkViaWorkerFactory+0x14 +0000009f`a3bffa80 00007ffe`83ca259d ntdll!TppWorkerThread+0x2ee +0000009f`a3bffd60 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a3bffd90 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 10 Id: 34c4.1768 Suspend: 1 Teb: 0000009f`a24c0000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a3dff438 00007ffe`8457a212 win32u!NtUserMsgWaitForMultipleObjectsEx+0x14 +0000009f`a3dff440 00007ffe`8456fa2e shcore!WorkThreadManager::CThread::ThreadProc+0xbf2 +0000009f`a3dff6f0 00007ffe`8456f9f1 shcore!WorkThreadManager::CThread::s_ExecuteThreadProc+0x22 +0000009f`a3dff730 00007ffe`83ca259d shcore!<lambda_9844335fc14345151eefcc3593dd6895>::<lambda_invoker_cdecl>+0x11 +0000009f`a3dff760 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a3dff790 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 11 Id: 34c4.3ac0 Suspend: 1 Teb: 0000009f`a24d6000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a41fead0 00007ffe`8506d249 ntdll!RtlpAllocateHeap+0x835 +0000009f`a41fed30 00007ffe`85134832 ntdll!RtlpAllocateHeapInternal+0x6c9 +0000009f`a41fee30 00007ffe`850ee2e8 ntdll!RtlDebugAllocateHeap+0x102 +0000009f`a41feed0 00007ffe`8506d249 ntdll!RtlpAllocateHeap+0x7f1a8 +0000009f`a41ff130 00007ffe`85059634 ntdll!RtlpAllocateHeapInternal+0x6c9 +0000009f`a41ff230 00007ffe`85058877 ntdll!LdrpAllocateTls+0x108 +0000009f`a41ff300 00007ffe`850a45af ntdll!LdrpInitializeThread+0x6f +0000009f`a41ff3e0 00007ffe`850a44e3 ntdll!_LdrpInitialize+0x93 +0000009f`a41ff460 00007ffe`850a440e ntdll!LdrpInitializeInternal+0x6b +0000009f`a41ff6e0 00000000`00000000 ntdll!LdrInitializeThunk+0xe + + 12 Id: 34c4.3fac Suspend: 1 Teb: 0000009f`a24c4000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a43ff268 00007ffe`85067e65 ntdll!NtWaitForAlertByThreadId+0x14 +0000009f`a43ff270 00007ff7`38b9edcd ntdll!RtlAcquireSRWLockExclusive+0x165 +0000009f`a43ff2e0 00007ff7`386771e6 qemu_system_x86_64!qemu_mutex_lock_impl+0x73 +0000009f`a43ff320 00007ff7`388b5654 qemu_system_x86_64!bql_lock_impl+0x78 +0000009f`a43ff370 00007ff7`388b5b00 qemu_system_x86_64!prepare_mmio_access+0x30 +0000009f`a43ff3b0 00007ff7`388b5c6c qemu_system_x86_64!flatview_read_continue_step+0xa0 +0000009f`a43ff430 00007ff7`388b5db9 qemu_system_x86_64!flatview_read_continue+0x66 +0000009f`a43ff480 00007ff7`388b5e60 qemu_system_x86_64!flatview_read+0xe2 +0000009f`a43ff500 00007ff7`388b5fb6 qemu_system_x86_64!address_space_read_full+0x78 +0000009f`a43ff570 00007ff7`38786ddf qemu_system_x86_64!address_space_rw+0x68 +0000009f`a43ff5c0 00007ffd`c624af05 qemu_system_x86_64!whpx_emu_ioport_callback+0x63 +0000009f`a43ff610 00007ffd`c62523d5 WinHvEmulation!IoPortHandler::NotifyIoPortRead+0x45 +0000009f`a43ff640 00007ffd`c624b916 WinHvEmulation!EmulatorVp::DispatchIoPortOperation+0x159 +0000009f`a43ff690 00007ffd`c624a77f WinHvEmulation!EmulatorVp::TrySimpleIoEmulation+0xc2 +0000009f`a43ff800 00007ffd`c6248caf WinHvEmulation!EmulatorWrapper::TryEmulationHelper<<lambda_6e350ef384ad69a259a7e747c2fadeeb> &>+0xcb +0000009f`a43ff8a0 00007ff7`38787201 WinHvEmulation!WHvEmulatorTryIoEmulation+0x10f +0000009f`a43ff930 00007ff7`38788cd6 qemu_system_x86_64!whpx_handle_portio+0x73 +0000009f`a43ff9a0 00007ff7`38789bd2 qemu_system_x86_64!whpx_vcpu_run+0x4a8 +0000009f`a43ffb20 00007ff7`3878c008 qemu_system_x86_64!whpx_vcpu_exec+0x54 +0000009f`a43ffb60 00007ff7`38b9faf2 qemu_system_x86_64!whpx_cpu_thread_fn+0xfb +0000009f`a43ffbb0 00007ffe`8424e634 qemu_system_x86_64!win32_start_routine+0x4e +0000009f`a43ffc00 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`a43ffc30 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`a43ffc60 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a43ffc90 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 13 Id: 34c4.3ecc Suspend: 1 Teb: 0000009f`a24c6000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a45ff8c8 00007ffe`829a9cee ntdll!NtWaitForSingleObject+0x14 +0000009f`a45ff8d0 00007ffd`e15631e2 KERNELBASE!WaitForSingleObjectEx+0x8e +0000009f`a45ff970 00007ffd`e156b621 WinHvPlatform!WHvApi::Processor::RunVp+0x486 +0000009f`a45ffbe0 00007ff7`38788b9a WinHvPlatform!WHvRunVirtualProcessor+0x31 +0000009f`a45ffc20 00007ff7`38789bd2 qemu_system_x86_64!whpx_vcpu_run+0x36c +0000009f`a45ffda0 00007ff7`3878c008 qemu_system_x86_64!whpx_vcpu_exec+0x54 +0000009f`a45ffde0 00007ff7`38b9faf2 qemu_system_x86_64!whpx_cpu_thread_fn+0xfb +0000009f`a45ffe30 00007ffe`8424e634 qemu_system_x86_64!win32_start_routine+0x4e +0000009f`a45ffe80 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`a45ffeb0 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`a45ffee0 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a45fff10 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 14 Id: 34c4.3d08 Suspend: 1 Teb: 0000009f`a24c8000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a47ff1a8 00007ffe`829a9cee ntdll!NtWaitForSingleObject+0x14 +0000009f`a47ff1b0 00007ffd`e15631e2 KERNELBASE!WaitForSingleObjectEx+0x8e +0000009f`a47ff250 00007ffd`e156b621 WinHvPlatform!WHvApi::Processor::RunVp+0x486 +0000009f`a47ff4c0 00007ff7`38788b9a WinHvPlatform!WHvRunVirtualProcessor+0x31 +0000009f`a47ff500 00007ff7`38789bd2 qemu_system_x86_64!whpx_vcpu_run+0x36c +0000009f`a47ff680 00007ff7`3878c008 qemu_system_x86_64!whpx_vcpu_exec+0x54 +0000009f`a47ff6c0 00007ff7`38b9faf2 qemu_system_x86_64!whpx_cpu_thread_fn+0xfb +0000009f`a47ff710 00007ffe`8424e634 qemu_system_x86_64!win32_start_routine+0x4e +0000009f`a47ff760 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`a47ff790 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`a47ff7c0 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a47ff7f0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 15 Id: 34c4.3eb4 Suspend: 1 Teb: 0000009f`a24ca000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a49ff278 00007ffe`829a9cee ntdll!NtWaitForSingleObject+0x14 +0000009f`a49ff280 00007ffd`e15631e2 KERNELBASE!WaitForSingleObjectEx+0x8e +0000009f`a49ff320 00007ffd`e156b621 WinHvPlatform!WHvApi::Processor::RunVp+0x486 +0000009f`a49ff590 00007ff7`38788b9a WinHvPlatform!WHvRunVirtualProcessor+0x31 +0000009f`a49ff5d0 00007ff7`38789bd2 qemu_system_x86_64!whpx_vcpu_run+0x36c +0000009f`a49ff750 00007ff7`3878c008 qemu_system_x86_64!whpx_vcpu_exec+0x54 +0000009f`a49ff790 00007ff7`38b9faf2 qemu_system_x86_64!whpx_cpu_thread_fn+0xfb +0000009f`a49ff7e0 00007ffe`8424e634 qemu_system_x86_64!win32_start_routine+0x4e +0000009f`a49ff830 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`a49ff860 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`a49ff890 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a49ff8c0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 16 Id: 34c4.3844 Suspend: 1 Teb: 0000009f`a24cc000 Unfrozen +Child-SP RetAddr Call Site +0000009f`a4bff328 00007ffe`829c6849 ntdll!NtWaitForMultipleObjects+0x14 +0000009f`a4bff330 00007ffd`cb215d94 KERNELBASE!WaitForMultipleObjectsEx+0xe9 +0000009f`a4bff610 00007ffd`cb21607a libglib_2_0_0!g_pattern_match_simple+0x214 +0000009f`a4bff690 00007ffd`cb216612 libglib_2_0_0!g_pattern_match_simple+0x4fa +0000009f`a4bff6e0 00007ffd`cb203740 libglib_2_0_0!g_poll+0x392 +0000009f`a4bffbd0 00007ffd`cb204180 libglib_2_0_0!g_get_monotonic_time+0xac0 +0000009f`a4bffc60 00007ffd`c9eaa829 libglib_2_0_0!g_main_loop_run+0x120 +0000009f`a4bffcb0 00007ffd`e5ab4e2b libspice_server_1!spice_server_init+0x1ca9 +0000009f`a4bffcf0 00007ffe`8424e634 libwinpthread_1!pthread_create_wrapper+0x9b +0000009f`a4bffd30 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`a4bffd60 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`a4bffd90 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`a4bffdc0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + +# 17 Id: 34c4.3b3c Suspend: 1 Teb: 0000009f`a24d8000 Unfrozen +Child-SP RetAddr Call Site +0000009f`c4dffd08 00007ffe`8510735e ntdll!DbgBreakPoint +0000009f`c4dffd10 00007ffe`83ca259d ntdll!DbgUiRemoteBreakin+0x4e +0000009f`c4dffd40 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`c4dffd70 00000000`00000000 ntdll!RtlUserThreadStart+0x28 + + 18 Id: 34c4.16c4 Suspend: 1 Teb: 0000009f`a24d0000 Unfrozen +Child-SP RetAddr Call Site +0000009f`c53ffb58 00007ffe`850997db ntdll!NtWaitForAlertByThreadId+0x14 +0000009f`c53ffb60 00007ffe`829df2e9 ntdll!RtlSleepConditionVariableSRW+0x13b +0000009f`c53ffbe0 00007ff7`38b9f403 KERNELBASE!SleepConditionVariableSRW+0x29 +0000009f`c53ffc20 00007ff7`38bbc9e5 qemu_system_x86_64!qemu_cond_timedwait_impl+0x92 +0000009f`c53ffc70 00007ff7`38b9faf2 qemu_system_x86_64!worker_thread+0xc9 +0000009f`c53ffce0 00007ffe`8424e634 qemu_system_x86_64!win32_start_routine+0x4e +0000009f`c53ffd30 00007ffe`8424e70c msvcrt!_callthreadstartex+0x28 +0000009f`c53ffd60 00007ffe`83ca259d msvcrt!_threadstartex+0x7c +0000009f`c53ffd90 00007ffe`8508af38 KERNEL32!BaseThreadInitThunk+0x1d +0000009f`c53ffdc0 00000000`00000000 ntdll!RtlUserThreadStart+0x28 +``` diff --git a/results/classifier/118/graphic/2750 b/results/classifier/118/graphic/2750 new file mode 100644 index 000000000..28671e51b --- /dev/null +++ b/results/classifier/118/graphic/2750 @@ -0,0 +1,41 @@ +graphic: 0.881 +device: 0.854 +performance: 0.777 +files: 0.652 +PID: 0.611 +debug: 0.597 +permissions: 0.597 +vnc: 0.576 +risc-v: 0.563 +boot: 0.488 +TCG: 0.468 +semantic: 0.465 +arm: 0.372 +network: 0.368 +ppc: 0.356 +socket: 0.348 +i386: 0.340 +architecture: 0.326 +register: 0.324 +x86: 0.231 +VMM: 0.166 +virtual: 0.164 +peripherals: 0.150 +user-level: 0.104 +mistranslation: 0.092 +hypervisor: 0.069 +kernel: 0.058 +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/118/graphic/2757 b/results/classifier/118/graphic/2757 new file mode 100644 index 000000000..627bc9fe6 --- /dev/null +++ b/results/classifier/118/graphic/2757 @@ -0,0 +1,31 @@ +graphic: 0.960 +performance: 0.847 +device: 0.678 +risc-v: 0.517 +arm: 0.482 +network: 0.405 +VMM: 0.397 +architecture: 0.391 +peripherals: 0.348 +boot: 0.346 +debug: 0.295 +ppc: 0.292 +PID: 0.232 +user-level: 0.196 +mistranslation: 0.164 +vnc: 0.150 +i386: 0.129 +permissions: 0.121 +socket: 0.113 +virtual: 0.092 +register: 0.088 +TCG: 0.071 +hypervisor: 0.065 +semantic: 0.062 +assembly: 0.049 +kernel: 0.042 +x86: 0.034 +files: 0.015 +KVM: 0.010 + +EGL can't handle multi plane textures diff --git a/results/classifier/118/graphic/2768 b/results/classifier/118/graphic/2768 new file mode 100644 index 000000000..b41dbcc92 --- /dev/null +++ b/results/classifier/118/graphic/2768 @@ -0,0 +1,46 @@ +ppc: 0.970 +register: 0.954 +graphic: 0.943 +architecture: 0.920 +device: 0.894 +performance: 0.843 +PID: 0.827 +files: 0.820 +semantic: 0.795 +debug: 0.700 +socket: 0.660 +peripherals: 0.575 +mistranslation: 0.570 +boot: 0.541 +vnc: 0.513 +permissions: 0.505 +network: 0.494 +TCG: 0.469 +user-level: 0.455 +kernel: 0.443 +arm: 0.347 +risc-v: 0.340 +hypervisor: 0.318 +assembly: 0.300 +VMM: 0.231 +virtual: 0.231 +KVM: 0.109 +x86: 0.020 +i386: 0.019 + +PowerPC e200 duplicate register definitions +Description of problem: +Registers DSRR0 and DSRR1 defined twice in the `target/ppc/cpu_init.c`: + +- in the common [`register_BookE_sprs()`](https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/cpu_init.c#L740-748) +- and specific [`init_proc_e200()`](https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/cpu_init.c#L2735-2742) + +The second case should be removed. +Steps to reproduce: +1. run `qemu-system-ppc -cpu e200z5` +2. check output +``` +** +ERROR:../qemu-9.2.0/target/ppc/helper_regs.c:410:_spr_register: assertion failed: (spr->name == ((void *)0)) +Bail out! ERROR:../qemu-9.2.0/target/ppc/helper_regs.c:410:_spr_register: assertion failed: (spr->name == ((void *)0)) +``` diff --git a/results/classifier/118/graphic/2783 b/results/classifier/118/graphic/2783 new file mode 100644 index 000000000..414aa5bd5 --- /dev/null +++ b/results/classifier/118/graphic/2783 @@ -0,0 +1,47 @@ +graphic: 0.932 +peripherals: 0.862 +virtual: 0.638 +performance: 0.518 +device: 0.486 +semantic: 0.454 +x86: 0.380 +boot: 0.370 +architecture: 0.274 +user-level: 0.215 +assembly: 0.197 +register: 0.195 +hypervisor: 0.188 +vnc: 0.140 +ppc: 0.140 +mistranslation: 0.132 +permissions: 0.120 +socket: 0.119 +kernel: 0.119 +debug: 0.115 +PID: 0.107 +VMM: 0.102 +network: 0.077 +files: 0.076 +risc-v: 0.076 +KVM: 0.067 +arm: 0.066 +TCG: 0.025 +i386: 0.023 + +Cannot install a fresh Windows 7 32-bit guest with Q35 machine type (mouse and keyboard do not function, so cannot continue install) +Description of problem: +When trying to install Windows 7 32-bit via the official SP1 installation ISO, the machine boots the installer, but both keyboard and mouse do not function, so the installation cannot proceed. +Steps to reproduce: +1. Using virt-manager, create a new VM using the x86 version of the Windows 7 SP1 install ISO found here: https://archive.org/details/windows-7-professional-with-sp1-x64-dvd-iso +2. Select `Microsoft Windows 7` as the Operating System type, which uses Q35 as the machine type +3. Click Begin Installation +4. See the Windows 7 installer screen show up +5. Keyboard and mouse inputs don't work at all, mouse cursor also doesn't appear +Additional information: +I've tried using `Microsoft Windows XP` as the Operating System in virt-manager, which switches to i440FX as the machine type, and the issue doesn't appear: keyboard and mouse both work perfectly. But of course, it would be nice to use Q35 instead to get USB 3.0, PCI-E, etc. + + +Notice the lack of cursor in the screenshot above on Q35. + +When using a i440FX machine, the white Windows cursor will appear: + diff --git a/results/classifier/118/graphic/2787 b/results/classifier/118/graphic/2787 new file mode 100644 index 000000000..b20f5a4b1 --- /dev/null +++ b/results/classifier/118/graphic/2787 @@ -0,0 +1,43 @@ +graphic: 0.829 +register: 0.784 +mistranslation: 0.779 +files: 0.757 +device: 0.742 +semantic: 0.708 +architecture: 0.702 +ppc: 0.622 +network: 0.604 +vnc: 0.535 +i386: 0.387 +TCG: 0.369 +kernel: 0.341 +virtual: 0.327 +performance: 0.314 +PID: 0.305 +arm: 0.305 +boot: 0.303 +VMM: 0.292 +user-level: 0.275 +debug: 0.273 +permissions: 0.270 +risc-v: 0.216 +peripherals: 0.216 +socket: 0.199 +x86: 0.163 +hypervisor: 0.066 +KVM: 0.037 +assembly: 0.003 + +Opentitan timer layout incorrect +Description of problem: +It looks as if some of the timer register offsets here are incorrect: + +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/timer/ibex_timer.c?ref_type=heads#L37 + +Compare with: + +https://opentitan.org/book/hw/ip/rv_timer/doc/registers.html + +I suspect they're out of date. The documentation link on line 7 is not working anymore - the current documentation URL for Opentitan is the one just given. + +It might also make sense to rename this file `opentitan_timer.c`, instead of `ibex_timer.c`. The timer is an Opentitan hardware IP block, rather than a feature of the Ibex CPU. diff --git a/results/classifier/118/graphic/2790 b/results/classifier/118/graphic/2790 new file mode 100644 index 000000000..269cb11dc --- /dev/null +++ b/results/classifier/118/graphic/2790 @@ -0,0 +1,40 @@ +graphic: 0.901 +device: 0.749 +performance: 0.703 +semantic: 0.594 +peripherals: 0.568 +architecture: 0.550 +debug: 0.455 +virtual: 0.393 +register: 0.389 +hypervisor: 0.329 +mistranslation: 0.323 +vnc: 0.316 +risc-v: 0.308 +PID: 0.305 +permissions: 0.298 +arm: 0.289 +ppc: 0.281 +boot: 0.279 +kernel: 0.250 +user-level: 0.250 +VMM: 0.229 +socket: 0.221 +TCG: 0.211 +network: 0.191 +i386: 0.173 +x86: 0.158 +KVM: 0.120 +files: 0.056 +assembly: 0.053 + +Can't switch to monitor with rr=record +Description of problem: +With the above args, while the guest is paused (either because I haven't attached GDB yet, or because I've halted execution in GDB), it's not possible to switch to the QEMU monitor. + +I don't reproduce this issue with `QEMU emulator version 8.2.4 (Debian 1:8.2.4+ds-1+build1)` but I do with 9.2 and master (built from source). + +AFAICT, the monitor is working - if I just set `-monitor stdio` instead of `-serial mon:stdio` I can use it, including when the VM is paused. But the multiplexing doesn't work. +Steps to reproduce: +1. Run the above +2. Ctrl-A, c diff --git a/results/classifier/118/graphic/2799 b/results/classifier/118/graphic/2799 new file mode 100644 index 000000000..6f8f39a37 --- /dev/null +++ b/results/classifier/118/graphic/2799 @@ -0,0 +1,71 @@ +graphic: 0.829 +files: 0.791 +user-level: 0.746 +PID: 0.673 +x86: 0.597 +device: 0.562 +architecture: 0.560 +kernel: 0.519 +socket: 0.501 +network: 0.494 +debug: 0.487 +permissions: 0.473 +i386: 0.443 +peripherals: 0.436 +vnc: 0.433 +ppc: 0.423 +mistranslation: 0.408 +TCG: 0.371 +semantic: 0.364 +risc-v: 0.349 +register: 0.342 +arm: 0.340 +boot: 0.334 +performance: 0.297 +VMM: 0.293 +hypervisor: 0.281 +KVM: 0.233 +virtual: 0.172 +assembly: 0.158 + +compile failure for linux-user when host libc defines "struct sched_attr" in its sched.h +Description of problem: +When I tried to build commit 871af84d the build process stopped in [3306/9698] Compiling C object libqemu...-linux-user.a.p/linux-user_syscall.c.o + +Here is the error log: + +``` +../linux-user/syscall.c:364:8: error: redefinition of 'struct sched_attr' + 364 | struct sched_attr { + | ^~~~~~~~~~ +In file included from /usr/include/bits/sched.h:63, + from /usr/include/sched.h:43, + from /usr/include/pthread.h:22, + from /usr/include/glib-2.0/glib/deprecated/gthread.h:126, + from /usr/include/glib-2.0/glib.h:115, + from /home/fred/qemu-git/src/qemu/include/glib-compat.h:32, + from /home/fred/qemu-git/src/qemu/include/qemu/osdep.h:161, + from ../linux-user/syscall.c:20: +/usr/include/linux/sched/types.h:98:8: note: originally defined here + 98 | struct sched_attr { + | ^~~~~~~~~~ +``` +Steps to reproduce: +1. Grab commit 871af84d +2. Use this configure command line: + +``` +--prefix=/usr \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --libexecdir=/usr/lib/qemu \ + --smbd=/usr/bin/smbd \ + --enable-modules \ + --enable-sdl \ + --disable-werror \ + "${@:2}" +``` + +3. Launch ninja and wait. +Additional information: + diff --git a/results/classifier/118/graphic/2806 b/results/classifier/118/graphic/2806 new file mode 100644 index 000000000..02e36addc --- /dev/null +++ b/results/classifier/118/graphic/2806 @@ -0,0 +1,39 @@ +graphic: 0.991 +device: 0.897 +architecture: 0.893 +arm: 0.863 +files: 0.843 +debug: 0.759 +network: 0.723 +PID: 0.689 +permissions: 0.678 +performance: 0.640 +vnc: 0.635 +semantic: 0.628 +register: 0.619 +ppc: 0.616 +user-level: 0.595 +boot: 0.499 +socket: 0.486 +peripherals: 0.441 +TCG: 0.440 +hypervisor: 0.427 +risc-v: 0.421 +mistranslation: 0.334 +kernel: 0.302 +VMM: 0.230 +i386: 0.215 +assembly: 0.172 +x86: 0.145 +virtual: 0.087 +KVM: 0.015 + +Build from source failed on Arch Linux with target-list=arm-softmmu,arm-linux-user +Description of problem: +When I tried to build the latest QEMU version, the build process top at 'linking test-qos' +Steps to reproduce: +1. Clone the latest git version of QEMU +2. Configure --target-list=arm-softmmu,arm-linux-user +3. Make +Additional information: + diff --git a/results/classifier/118/graphic/2807 b/results/classifier/118/graphic/2807 new file mode 100644 index 000000000..4e5057550 --- /dev/null +++ b/results/classifier/118/graphic/2807 @@ -0,0 +1,61 @@ +graphic: 0.895 +boot: 0.891 +ppc: 0.880 +device: 0.869 +performance: 0.851 +peripherals: 0.824 +vnc: 0.759 +architecture: 0.741 +user-level: 0.738 +debug: 0.662 +hypervisor: 0.630 +x86: 0.591 +semantic: 0.532 +i386: 0.477 +register: 0.470 +network: 0.467 +permissions: 0.465 +kernel: 0.464 +virtual: 0.456 +socket: 0.436 +assembly: 0.369 +PID: 0.342 +risc-v: 0.308 +TCG: 0.300 +arm: 0.296 +VMM: 0.249 +files: 0.239 +mistranslation: 0.221 +KVM: 0.150 + +DOUBLE MMU FAULT when running -M virt in qemu-system-m68k +Description of problem: +When running qemu-system-m68k with the -M virt machine type, a DOUBLE MMU FAULT occurs immediately upon startup, even without any BIOS, disk image, or additional configuration. +Steps to reproduce: +1. qemu-system-m68k -M virt -m 4M -serial stdio + +QEMU crashes immediately with the following output: +``` +qemu: fatal: DOUBLE MMU FAULT +D0 = 00000000 A0 = 00000000 F0 = 7fff ffffffffffffffff ( nan) +D1 = 00000000 A1 = 00000000 F1 = 7fff ffffffffffffffff ( nan) +D2 = 00000000 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) +D3 = 00000000 A3 = 00000000 F3 = 7fff ffffffffffffffff ( nan) +D4 = 00000000 A4 = 00000000 F4 = 7fff ffffffffffffffff ( nan) +D5 = 00000000 A5 = 00000000 F5 = 7fff ffffffffffffffff ( nan) +D6 = 00000000 A6 = 00000000 F6 = 7fff ffffffffffffffff ( nan) +D7 = 00000000 A7 = 00000000 F7 = 7fff ffffffffffffffff ( nan) +PC = 00400000 SR = 2704 T:0 I:7 SI --Z-- +FPSR = 00000000 ---- + FPCR = 0000 X RN + A7(MSP) = 00000000 A7(USP) = 00000000 ->A7(ISP) = 00000000 +VBR = 0x00000000 +SFC = 0 DFC 0 +SSW 00000105 TCR 00000000 URP 00000000 SRP 00000000 +DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000 +MMUSR 00000000, fault at fffffffc +``` +Additional information: +The issue seems to be related to incorrect memory initialization, causing a fault at address fffffffc. +The PC = 00400000 suggests that QEMU is jumping to an invalid address early in the boot process. +The fact that the fault is consistent across different configurations (q800, next-cube, etc) points to a possible regression or incomplete memory initialization in the virt machine. diff --git a/results/classifier/118/graphic/2809 b/results/classifier/118/graphic/2809 new file mode 100644 index 000000000..0a8f73680 --- /dev/null +++ b/results/classifier/118/graphic/2809 @@ -0,0 +1,41 @@ +graphic: 0.846 +device: 0.807 +performance: 0.802 +debug: 0.645 +files: 0.551 +vnc: 0.524 +permissions: 0.505 +semantic: 0.440 +ppc: 0.429 +network: 0.377 +boot: 0.371 +PID: 0.359 +socket: 0.335 +i386: 0.324 +TCG: 0.297 +risc-v: 0.231 +arm: 0.215 +x86: 0.215 +architecture: 0.204 +register: 0.137 +VMM: 0.110 +user-level: 0.105 +virtual: 0.096 +mistranslation: 0.084 +peripherals: 0.082 +kernel: 0.078 +hypervisor: 0.032 +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/118/graphic/2818 b/results/classifier/118/graphic/2818 new file mode 100644 index 000000000..2386df718 --- /dev/null +++ b/results/classifier/118/graphic/2818 @@ -0,0 +1,37 @@ +graphic: 0.883 +performance: 0.866 +device: 0.848 +network: 0.789 +semantic: 0.788 +debug: 0.761 +architecture: 0.710 +kernel: 0.629 +socket: 0.629 +PID: 0.612 +peripherals: 0.608 +vnc: 0.601 +files: 0.590 +TCG: 0.558 +arm: 0.557 +i386: 0.553 +boot: 0.552 +user-level: 0.526 +ppc: 0.522 +VMM: 0.519 +risc-v: 0.482 +register: 0.453 +x86: 0.437 +mistranslation: 0.411 +hypervisor: 0.381 +virtual: 0.299 +KVM: 0.273 +assembly: 0.251 +permissions: 0.209 + +Passing `-M microvm` and `-smbios type=11...` results in smbios args being silently dropped +Description of problem: +(reporting as requested by `danpb` on IRC) + +Using the `-machine microvm` flag with the `smbios type=11...` argument results in the smbios options being silently discarded, because the microvm target doesn't seem to support the smbios feature. + +danpb on IRC suggested that passing those two incompatible flags should result in an error. diff --git a/results/classifier/118/graphic/2822 b/results/classifier/118/graphic/2822 new file mode 100644 index 000000000..035c5a5b6 --- /dev/null +++ b/results/classifier/118/graphic/2822 @@ -0,0 +1,41 @@ +graphic: 0.858 +performance: 0.799 +device: 0.793 +debug: 0.562 +files: 0.551 +vnc: 0.511 +boot: 0.434 +semantic: 0.428 +TCG: 0.398 +ppc: 0.386 +permissions: 0.385 +i386: 0.373 +PID: 0.319 +arm: 0.296 +risc-v: 0.268 +x86: 0.251 +architecture: 0.234 +register: 0.144 +socket: 0.127 +mistranslation: 0.126 +user-level: 0.095 +virtual: 0.089 +VMM: 0.085 +hypervisor: 0.079 +network: 0.073 +peripherals: 0.060 +assembly: 0.026 +KVM: 0.020 +kernel: 0.017 + +Data race with state field of ThreadPoolElement +Description of problem: +A data race in the access of `ThreadPoolElement` state field in `util/thread-pool.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-thread-pool +MALLOC_PERTURB_=111 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-thread-pool --tap -k +``` diff --git a/results/classifier/118/graphic/2828 b/results/classifier/118/graphic/2828 new file mode 100644 index 000000000..797f360c9 --- /dev/null +++ b/results/classifier/118/graphic/2828 @@ -0,0 +1,33 @@ +graphic: 0.901 +architecture: 0.889 +risc-v: 0.881 +device: 0.819 +semantic: 0.791 +debug: 0.768 +ppc: 0.715 +performance: 0.656 +arm: 0.605 +socket: 0.570 +virtual: 0.467 +vnc: 0.465 +mistranslation: 0.440 +VMM: 0.393 +PID: 0.382 +network: 0.349 +i386: 0.340 +TCG: 0.328 +boot: 0.322 +kernel: 0.304 +register: 0.284 +KVM: 0.179 +files: 0.160 +assembly: 0.156 +hypervisor: 0.127 +permissions: 0.099 +x86: 0.081 +user-level: 0.055 +peripherals: 0.045 + +Potential issues at Interrupt filtering and virtual interrupts for supervisor level (RISC-V AIA) +Description of problem: +I am working on RISC-V Advanced Interrupt Architecture (AIA) compliance tests for our RISC-V core. These tests pass on our hardware implementation but fail when running on QEMU. There are several points where the tests fail while running in QEMU: diff --git a/results/classifier/118/graphic/2836 b/results/classifier/118/graphic/2836 new file mode 100644 index 000000000..43352807b --- /dev/null +++ b/results/classifier/118/graphic/2836 @@ -0,0 +1,73 @@ +user-level: 0.955 +graphic: 0.942 +PID: 0.932 +semantic: 0.930 +permissions: 0.929 +vnc: 0.928 +device: 0.925 +performance: 0.899 +hypervisor: 0.899 +architecture: 0.892 +peripherals: 0.888 +debug: 0.886 +risc-v: 0.884 +x86: 0.879 +network: 0.870 +files: 0.864 +socket: 0.843 +register: 0.832 +virtual: 0.821 +mistranslation: 0.820 +ppc: 0.818 +assembly: 0.815 +arm: 0.811 +VMM: 0.809 +kernel: 0.803 +KVM: 0.774 +TCG: 0.771 +i386: 0.750 +boot: 0.732 + +readconfig with [vnc] only causes assertion failure +Description of problem: +Given test.config containing +``` +[vnc] +``` + +``` +$ qemu-system-amd64 -readconfig test.config +qemu-system-amd64: ui/vnc.c:4294: vnc_init_func: Assertion `id' failed. +Aborted +``` + + +``` +(gdb) bt +#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) + at ./nptl/pthread_kill.c:44 +#1 0x00007ffff68f3e2f in __pthread_kill_internal (threadid=<optimized out>, signo=6) at ./nptl/pthread_kill.c:78 +#2 0x00007ffff689fd02 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 +#3 0x00007ffff68884f0 in __GI_abort () at ./stdlib/abort.c:79 +#4 0x00007ffff6888418 in __assert_fail_base (fmt=0x7ffff6a0cca0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", + assertion=assertion@entry=0x55555608eef6 "id", file=file@entry=0x555556068a5e "ui/vnc.c", line=line@entry=4294, + function=function@entry=0x5555561c3fe0 <__PRETTY_FUNCTION__.0> "vnc_init_func") at ./assert/assert.c:96 +#5 0x00007ffff6898612 in __assert_fail (assertion=assertion@entry=0x55555608eef6 "id", + file=file@entry=0x555556068a5e "ui/vnc.c", line=line@entry=4294, + function=function@entry=0x5555561c3fe0 <__PRETTY_FUNCTION__.0> "vnc_init_func") at ./assert/assert.c:105 +#6 0x0000555555a03adb in vnc_init_func (opaque=<optimized out>, opts=<optimized out>, + errp=0x5555570db038 <error_fatal>) at ui/vnc.c:4294 +#7 0x0000555556037b31 in qemu_opts_foreach (list=<optimized out>, func=0x555555a039f0 <vnc_init_func>, + opaque=opaque@entry=0x0, errp=errp@entry=0x5555570db038 <error_fatal>) at util/qemu-option.c:1135 +#8 0x0000555555c41eff in qemu_init_displays () at system/vl.c:2619 +#9 qemu_init (argc=<optimized out>, argv=<optimized out>) at system/vl.c:3762 +#10 0x00005555559e1c0d in main (argc=<optimized out>, argv=<optimized out>) at system/main.c:47 +``` + +https://gitlab.com/qemu-project/qemu/-/blob/master/ui/vnc.c#L4294 + +Passing an invalid value to id results in `qemu-system-amd64: -readconfig test.config: Parameter 'id' expects an identifier +Identifiers consist of letters, digits, '-', '.', '_', starting with a letter.` so perhaps a missing value should cause a similar error? + + +PS: Where's the documentation for `-readconfig`? diff --git a/results/classifier/118/graphic/2851 b/results/classifier/118/graphic/2851 new file mode 100644 index 000000000..35d629dec --- /dev/null +++ b/results/classifier/118/graphic/2851 @@ -0,0 +1,81 @@ +graphic: 0.873 +virtual: 0.797 +permissions: 0.785 +user-level: 0.772 +semantic: 0.766 +register: 0.736 +architecture: 0.730 +device: 0.715 +performance: 0.706 +files: 0.688 +PID: 0.679 +assembly: 0.677 +debug: 0.665 +network: 0.659 +x86: 0.657 +arm: 0.653 +peripherals: 0.646 +socket: 0.625 +KVM: 0.607 +boot: 0.587 +TCG: 0.585 +risc-v: 0.573 +kernel: 0.572 +vnc: 0.568 +VMM: 0.565 +mistranslation: 0.555 +hypervisor: 0.551 +i386: 0.528 +ppc: 0.526 + +Assert failure in ../util/error.c:68: void error_setv() +Description of problem: +If bdrv_snapshot_goto() returns an error, it is not handled immediately, +allowing *errp to be reassigned when qcow_open() fails, which triggers +assert(*errp == NULL) in util/error.c: void error_setv(). +Steps to reproduce: +1. [test.qed](/uploads/17005dfba241f5a355e3592e12e356f6/test.qed) +2. ./qemu-img snapshot -q -a test test.qed +Additional information: +<details> +<pre> +qemu-img-fuzz: ../util/error.c:68: void error_setv(Error **, const char *, int, const char *, ErrorClass, const char *, struct __va_list_tag *, const char *): Assertion `*errp == NULL' failed. +==20841== ERROR: libFuzzer: deadly signal + #0 0x56384b84a46a in __sanitizer_print_stack_trace /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x56384b79bb79 in fuzzer::PrintStackTrace() /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x56384b77d5a6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:18 + #3 0x56384b77d667 in fuzzer::Fuzzer::CrashCallback() /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:205:1 + #4 0x56384b77d667 in fuzzer::Fuzzer::StaticCrashSignalCallback() /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:204:19 + #5 0x7effd07c09df (/lib64/libpthread.so.0+0x139df) + #6 0x7effcf659450 in raise (/lib64/libc.so.6+0x3d450) + #7 0x7effcf642547 in abort (/lib64/libc.so.6+0x26547) + #8 0x7effcf642430 (/lib64/libc.so.6+0x26430) + #9 0x7effcf651ce1 in __assert_fail (/lib64/libc.so.6+0x35ce1) + #10 0x56384bf211dc in error_setv /home/gerben/qemu-img_fuzz/build/../util/error.c:68:5 + #11 0x56384bf213fc in error_setg_internal /home/gerben/qemu-img_fuzz/build/../util/error.c:105:5 + #12 0x56384bb2b71f in qcow_open /home/gerben/qemu-img_fuzz/build/../block/qcow.c:306:5 + #13 0x56384bb17654 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:299:20 + #14 0x56384bdd52c1 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img-wrapper.c:3476:15 + #15 0x56384bdbcede in qemu_img_main /home/gerben/qemu-img_fuzz/build/../qemu-img-wrapper.c:5624:20 + #16 0x56384bdb6e7d in command_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img_fuzz.c:309:20 + #17 0x56384bdb6e7d in generator_command /home/gerben/qemu-img_fuzz/build/../qemu-img_fuzz.c:1285:17 + #18 0x56384bdaf718 in LLVMFuzzerTestOneInput /home/gerben/qemu-img_fuzz/build/../qemu-img_fuzz.c:1303:5 + #19 0x56384b77e1c8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:559:17 + #20 0x56384b781af0 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:471:18 + #21 0x56384b784796 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:771:13 + #22 0x56384b784c7e in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:800:28 + #23 0x56384b76bb57 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:847:10 + #24 0x56384b758fe2 in main /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #25 0x7effcf643efc in __libc_start_main (/lib64/libc.so.6+0x27efc) + #26 0x56384b759089 in _start /usr/src/RPM/BUILD/glibc-2.32-alt5.p10.3/csu/../sysdeps/x86_64/start.S:120 + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +0x2b,0x25,0xff,0xff,0xff,0xff,0x3a,0x9a,0xc9,0xff,0xa, ++%\xff\xff\xff\xff:\x9a\xc9\xff\x0a +artifact_prefix='./'; Test unit written to ./crash-e9c4f1b8a97ffa93544e87a5a819ac524aa82029 +Base64: KyX/////OprJ/wo= +</pre> +</details> diff --git a/results/classifier/118/graphic/2853 b/results/classifier/118/graphic/2853 new file mode 100644 index 000000000..c1199fbca --- /dev/null +++ b/results/classifier/118/graphic/2853 @@ -0,0 +1,84 @@ +graphic: 0.807 +VMM: 0.756 +TCG: 0.753 +performance: 0.738 +x86: 0.732 +permissions: 0.731 +peripherals: 0.723 +hypervisor: 0.716 +semantic: 0.713 +risc-v: 0.713 +architecture: 0.709 +KVM: 0.707 +debug: 0.705 +network: 0.698 +ppc: 0.695 +vnc: 0.692 +register: 0.681 +virtual: 0.674 +arm: 0.671 +device: 0.665 +PID: 0.657 +files: 0.645 +user-level: 0.638 +mistranslation: 0.633 +socket: 0.628 +boot: 0.596 +kernel: 0.592 +assembly: 0.589 +i386: 0.566 + +double-free in vmdk_add_extent() +Description of problem: +A double-free issue in the VMDK driver occurs when handling snapshots. +The memory allocated for extent structures is freed twice: first in +vmdk_close (block/vmdk.c) and then in vmdk_add_extent (block/vmdk.c). +Steps to reproduce: +1. [test.raw](/uploads/deeb9dc3cab1916adadd211173cd175a/test.raw) +2. ./qemu-img snapshot -q -a test test.raw +Additional information: +<details> +<pre> +./qemu-img snapshot -q -a test test.raw +==18180==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +================================================================= +==18180==ERROR: AddressSanitizer: attempting double-free on 0x612000011bc0 in thread T0: + #0 0x5605ba505168 in realloc /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3 + #1 0x7f22be5fd6b7 in g_realloc (/lib64/libglib-2.0.so.0+0x5c6b7) + #2 0x5605ba866a79 in vmdk_add_extent /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:570:18 + #3 0x5605ba86122e in vmdk_open_vmdk4 /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1059:11 + #4 0x5605ba86122e in vmdk_open_sparse /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1127:20 + #5 0x5605ba85723a in vmdk_open /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1371:19 + #6 0x5605ba803ca4 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:299:20 + #7 0x5605baa8cdd2 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3500:15 + #8 0x7f22bd559efc in __libc_start_main (/lib64/libc.so.6+0x27efc) + #9 0x5605ba4619f9 in _start /usr/src/RPM/BUILD/glibc-2.32-alt5.p10.3/csu/../sysdeps/x86_64/start.S:120 + +0x612000011bc0 is located 0 bytes inside of 272-byte region [0x612000011bc0,0x612000011cd0) +freed by thread T0 here: + #0 0x5605ba504aef in free /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3 + #1 0x5605ba857e6d in vmdk_close /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:2889:5 + #2 0x5605ba803bb2 in bdrv_snapshot_goto /home/gerben/qemu-img_fuzz/build/../block/snapshot.c:290:13 + #3 0x5605baa8cdd2 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3500:15 + #4 0x7f22bd559efc in __libc_start_main (/lib64/libc.so.6+0x27efc) + +previously allocated by thread T0 here: + #0 0x5605ba505168 in realloc /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3 + #1 0x7f22be5fd6b7 in g_realloc (/lib64/libglib-2.0.so.0+0x5c6b7) + #2 0x5605ba86122e in vmdk_open_vmdk4 /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1059:11 + #3 0x5605ba86122e in vmdk_open_sparse /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1127:20 + #4 0x5605ba85723a in vmdk_open /home/gerben/qemu-img_fuzz/build/../block/vmdk.c:1371:19 + #5 0x5605ba56e3a2 in bdrv_open_driver /home/gerben/qemu-img_fuzz/build/../block.c:1660:15 + #6 0x5605ba57ea50 in bdrv_open_common /home/gerben/qemu-img_fuzz/build/../block.c:1985:11 + #7 0x5605ba57ea50 in bdrv_open_inherit /home/gerben/qemu-img_fuzz/build/../block.c:4153:11 + #8 0x5605ba585cb8 in bdrv_open /home/gerben/qemu-img_fuzz/build/../block.c:4248:12 + #9 0x5605ba637d4c in blk_new_open /home/gerben/qemu-img_fuzz/build/../block/block-backend.c:457:10 + #10 0x5605baa9193b in img_open_file /home/gerben/qemu-img_fuzz/build/../qemu-img.c:405:11 + #11 0x5605baa9143e in img_open /home/gerben/qemu-img_fuzz/build/../qemu-img.c:450:15 + #12 0x5605baa8cc71 in img_snapshot /home/gerben/qemu-img_fuzz/build/../qemu-img.c:3468:11 + #13 0x7f22bd559efc in __libc_start_main (/lib64/libc.so.6+0x27efc) + +SUMMARY: AddressSanitizer: double-free /usr/src/RPM/BUILD/llvm-11.0.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:164:3 in realloc +==18180==ABORTING +</pre> +</details> diff --git a/results/classifier/118/graphic/2874 b/results/classifier/118/graphic/2874 new file mode 100644 index 000000000..59e1504ca --- /dev/null +++ b/results/classifier/118/graphic/2874 @@ -0,0 +1,39 @@ +graphic: 0.967 +device: 0.899 +x86: 0.793 +performance: 0.762 +semantic: 0.672 +architecture: 0.633 +debug: 0.627 +mistranslation: 0.589 +arm: 0.541 +network: 0.487 +user-level: 0.418 +kernel: 0.413 +permissions: 0.389 +ppc: 0.384 +PID: 0.382 +socket: 0.377 +TCG: 0.356 +vnc: 0.353 +boot: 0.330 +register: 0.310 +files: 0.300 +risc-v: 0.294 +VMM: 0.291 +i386: 0.267 +hypervisor: 0.163 +assembly: 0.157 +virtual: 0.135 +peripherals: 0.129 +KVM: 0.107 + +AMD Ryzen 9950x with -smp option yields "warning: This family of AMD CPU doesn't support hyperthreading" +Description of problem: +When using the above -smp option (`-smp 32,sockets=1,dies=1,clusters=1,cores=16,threads=2`), which should be valid for the Ryzen 9950X 16 cores / 32 threads CPU, QEMU prints: +``` +qemu-system-x86_64: warning: This family of AMD CPU doesn't support hyperthreading(2). Please configure -smp options properly or try enabling topoext feature. +``` +This is unexpected. This CPU should support hyperthreading out of the box, it seems. +Steps to reproduce: +1. Run command above on Ryzen 9950X or similar CPU. diff --git a/results/classifier/118/graphic/2897 b/results/classifier/118/graphic/2897 new file mode 100644 index 000000000..aea99c2f1 --- /dev/null +++ b/results/classifier/118/graphic/2897 @@ -0,0 +1,44 @@ +graphic: 0.966 +boot: 0.904 +device: 0.847 +x86: 0.713 +architecture: 0.681 +performance: 0.677 +vnc: 0.667 +semantic: 0.640 +hypervisor: 0.551 +debug: 0.543 +virtual: 0.534 +network: 0.497 +user-level: 0.458 +PID: 0.430 +i386: 0.408 +VMM: 0.398 +register: 0.353 +risc-v: 0.338 +mistranslation: 0.319 +arm: 0.295 +permissions: 0.261 +socket: 0.232 +TCG: 0.226 +ppc: 0.224 +files: 0.216 +peripherals: 0.194 +KVM: 0.171 +kernel: 0.138 +assembly: 0.118 + +Can't boot SeaBIOS based VM when using -display gtk, works fine with vnc or sdl +Description of problem: +When using -display gtk, SeaBIOS hangs nondeterministicly. Changing to -display sdl or -display vnc lets it boot. +Steps to reproduce: +1. Run `qemu-system-x86_64 -display gtk` and the VM will not complete BIOS POST. +2. Run `qemu-system-x86_64 -display sdl` and the VM will complete BIOS POST. +Additional information: +This ONLY happens with SeaBIOS. Using a UEFI BIOS to boot the VM does not cause this issue. + +I realise this is a crazy bug. I suspect that the only way it could have slipped through testing is because it *requires* human interaction. + +There is no difference with using --accel kvm or not, but I have provided the smallest possible command line to duplicate the issue, which is literally just `qemu-system-x86_64 -display gtk` + +# diff --git a/results/classifier/118/graphic/2908 b/results/classifier/118/graphic/2908 new file mode 100644 index 000000000..80bf5d930 --- /dev/null +++ b/results/classifier/118/graphic/2908 @@ -0,0 +1,40 @@ +graphic: 0.989 +device: 0.962 +files: 0.918 +peripherals: 0.888 +architecture: 0.872 +socket: 0.871 +semantic: 0.839 +performance: 0.835 +PID: 0.829 +network: 0.825 +vnc: 0.797 +register: 0.796 +ppc: 0.776 +user-level: 0.675 +mistranslation: 0.659 +permissions: 0.621 +boot: 0.613 +risc-v: 0.591 +debug: 0.517 +virtual: 0.437 +hypervisor: 0.425 +arm: 0.388 +assembly: 0.385 +kernel: 0.355 +TCG: 0.351 +VMM: 0.347 +i386: 0.343 +x86: 0.334 +KVM: 0.140 + +Display Output Not Sane After Driver Installation +Description of problem: +Using an S3 Diamond Stealth 3000 card through VFIO, after installing an official driver, either from the Windows disc or an updated download, the displayed output from the graphics card is not sane. +Additional information: +Driver: [https://theretroweb.com/expansioncards/s/diamond-stealth-3d-3000-pci#driver](https://theretroweb.com/expansioncards/s/diamond-stealth-3d-3000-pci#driver) +[https://diamond.retropc.se/driver/stealth/st3d3xx0/files.htm](https://diamond.retropc.se/driver/stealth/st3d3xx0/files.htm) + +Followed the instructions in the Readme. To install Standard VGA driver first then the Diamond 3000 driver. No change. It is not the only S3 card that I have tried that behaves like this. I have also used the bios rom downloaded directly from the card, again with no change. + +# diff --git a/results/classifier/118/graphic/2909 b/results/classifier/118/graphic/2909 new file mode 100644 index 000000000..ca0fd29ff --- /dev/null +++ b/results/classifier/118/graphic/2909 @@ -0,0 +1,48 @@ +graphic: 0.888 +device: 0.830 +ppc: 0.626 +mistranslation: 0.618 +semantic: 0.592 +performance: 0.469 +register: 0.468 +hypervisor: 0.458 +vnc: 0.417 +assembly: 0.412 +debug: 0.400 +i386: 0.393 +risc-v: 0.366 +PID: 0.365 +virtual: 0.361 +VMM: 0.356 +x86: 0.349 +KVM: 0.344 +boot: 0.336 +architecture: 0.321 +permissions: 0.314 +socket: 0.273 +kernel: 0.267 +arm: 0.225 +TCG: 0.215 +user-level: 0.198 +peripherals: 0.168 +network: 0.167 +files: 0.042 + +Corrupt qcow2 images with broken bitmap unfixable +Description of problem: +During a backup of a VM (via bitmaps), the disk of the VM/Snapshot went out of space. +The VM was stopped, leaving the image in a bad state. + +But now when trying to repair it, it was stuck: +``` +# qemu-img check -r all /dev/mapper/e1d2ff33--c3fd--4c1a--bcd1--2047e4efc362-efbd8056--720a--47b6--bede--4325d576ffb9 +qemu-img: Could not open '/dev/mapper/e1d2ff33--c3fd--4c1a--bcd1--2047e4efc362-efbd8056--720a--47b6--bede--4325d576ffb9': Bitmap '' doesn't satisfy the constraints +``` + +But if you want to remove the bitmap: +``` +# qemu-img bitmap --remove /dev/mapper/e1d2ff33--c3fd--4c1a--bcd1--2047e4efc362-efbd8056--720a--47b6--bede--4325d576ffb9 '' +qemu-img: Could not open '/dev/mapper/e1d2ff33--c3fd--4c1a--bcd1--2047e4efc362-efbd8056--720a--47b6--bede--4325d576ffb9': qcow2: Image is corrupt; cannot be opened read/write +``` + +It seems like qemu-img check needs some option to clear invalid bitmaps. So the image can be repaired including dropping the invalid bitmap. diff --git a/results/classifier/118/graphic/2916 b/results/classifier/118/graphic/2916 new file mode 100644 index 000000000..d8201ebb3 --- /dev/null +++ b/results/classifier/118/graphic/2916 @@ -0,0 +1,56 @@ +arm: 0.963 +graphic: 0.933 +register: 0.927 +architecture: 0.921 +device: 0.898 +performance: 0.881 +semantic: 0.875 +peripherals: 0.805 +debug: 0.774 +network: 0.726 +permissions: 0.693 +ppc: 0.676 +mistranslation: 0.660 +x86: 0.647 +user-level: 0.640 +PID: 0.618 +vnc: 0.598 +assembly: 0.593 +socket: 0.584 +TCG: 0.577 +hypervisor: 0.515 +VMM: 0.503 +risc-v: 0.495 +kernel: 0.412 +virtual: 0.381 +i386: 0.364 +boot: 0.352 +files: 0.281 +KVM: 0.267 + +qemu-system-arm hangs when attempting to enable MMU on Cortex-A7 +Description of problem: +QEMU 9.x.x+ hangs when attempting to do enable the MMU from SCTLRL - M bit: https://developer.arm.com/documentation/ddi0601/2025-03/AArch32-Registers/SCTLR--System-Control-Register + +The instruction that hangs is the writing of the SCTLR register: + +``` +mrc p15, 0, r0, c1, c0, 0 +orr r0, r0, 1 +mcr p15, 0, r0, c1, c0, 0 +``` + +I am attempting to enable unaligned accesses and SCTLR-A bit doesn't seem to have any effect if the SCTLR-M is not enabled. Doing an unaligned access on cortex-a7 should be supported but it always trigger a Fault. +Steps to reproduce: +1. add the mrc/orr/mcr instruction sequence in the ResetHandler +2. link the elf +3. attempt to execute it +Additional information: +The unaligned access looked like it was working in QEMU 8.x.x but it might not have been emulated(?). I also am facing the same issues with MCR hanging and unaligned access not supported with latest 10.0.0-RC2. + +When it hangs, QEMU has to be killed and terminal reset. + +There might be two separate issues here: + +1. writing SCTLR register +2. emulated cortex-a7 not supporting unaligned access (hardware supports it) diff --git a/results/classifier/118/graphic/2920 b/results/classifier/118/graphic/2920 new file mode 100644 index 000000000..c8d8b4c40 --- /dev/null +++ b/results/classifier/118/graphic/2920 @@ -0,0 +1,42 @@ +graphic: 0.970 +performance: 0.962 +peripherals: 0.945 +device: 0.895 +architecture: 0.740 +semantic: 0.613 +PID: 0.590 +permissions: 0.565 +risc-v: 0.552 +register: 0.538 +vnc: 0.523 +ppc: 0.509 +mistranslation: 0.484 +boot: 0.462 +debug: 0.425 +socket: 0.391 +arm: 0.386 +user-level: 0.351 +VMM: 0.307 +files: 0.305 +KVM: 0.233 +TCG: 0.211 +i386: 0.197 +kernel: 0.165 +assembly: 0.129 +x86: 0.125 +virtual: 0.118 +network: 0.062 +hypervisor: 0.039 + +VGA Passthrough I/O Lag on DOS (FreeDOS) System. +Description of problem: +VGA performance lags with passthrough when the OS is in graphics mode. It also seems to affect when key presses are registered with noticeable delay. +Steps to reproduce: +1. Install Doom (v1.9 Shareware.) +2. Run setup and disable sound. +3. Play game or watch demo. +Additional information: +I have tried multiple cards with no change in performance: + +**VGA compatible controller: S3 Graphics Ltd. 86c375 [ViRGE/DX] or 86c385 [ViRGE/GX] (rev 01) (prog-if 00 [VGA controller]) +VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] R480 [Radeon X800 GTO] (prog-if 00 [VGA controller])** diff --git a/results/classifier/118/graphic/2926 b/results/classifier/118/graphic/2926 new file mode 100644 index 000000000..678b89643 --- /dev/null +++ b/results/classifier/118/graphic/2926 @@ -0,0 +1,66 @@ +graphic: 0.978 +files: 0.948 +performance: 0.945 +KVM: 0.929 +peripherals: 0.923 +x86: 0.923 +architecture: 0.911 +PID: 0.899 +kernel: 0.891 +hypervisor: 0.889 +device: 0.885 +semantic: 0.818 +virtual: 0.814 +ppc: 0.789 +VMM: 0.785 +permissions: 0.775 +debug: 0.771 +mistranslation: 0.749 +user-level: 0.747 +register: 0.731 +socket: 0.715 +arm: 0.687 +boot: 0.685 +network: 0.685 +vnc: 0.674 +i386: 0.668 +risc-v: 0.640 +assembly: 0.625 +TCG: 0.551 + +Excessive memory allocation on guest and host with gpu passthrough +Description of problem: +While gpu passthrough is enabled, the maximum amount of ram is allocated on the host (64 GB), even if the guest only has 8 GB configured as "currently allocated". +If I disable the physical gpu, the guest only takes the 8 GB. +Steps to reproduce: +1. Install qemu-kvm virt-manager libvirt-daemon-system virtinst libvirt-clients and bridge-utils. +1. Create a Windows vm with virt-manager +1. Insert discrete GPU on a secondary pcie slot. +1. Add `intel_iommu=on iommu=pt vfio-pci.ids=10de:17c8,10de:0fb0` to the GRUB kernel parameters. +1. Add `options vfio-pci ids=10de:17c8,10de:0fb0` and `softdep nvidia pre: vfio-pci` to `/etc/modprobe.d/vfio.conf`. +1. Update initrmfs image. +1. Add pcie hardware on virt-manager. +1. Install virtio and nvidia drivers on guest. +Additional information: +I'm using an Nvidia gtx 980Ti on a secondary slot for the guest. +The first slot has an rtx 4090 used by the host. + +``` +OS: Linux Mint 22.1 x86_64 +Host: MS-7E07 2.0 +Kernel: 6.8.0-51-generic +Shell: bash 5.2.21 +Resolution: 3840x2160, 3840x2160 +DE: Cinnamon 6.4.8 +WM: Mutter (Muffin) +Terminal: gnome-terminal +CPU: Intel i9-14900K (32) @ 5.700GHz +GPU: NVIDIA GeForce GTX 980 Ti +GPU: NVIDIA GeForce RTX 4090 +GPU: Intel Raptor Lake-S GT1 [UHD Graphics 770] +Memory: 73717MiB / 96317MiB +``` + +[vWin.xml](/uploads/3fe8133f67577f8724b060908b390c32/vWin.xml) +[vWin.log](/uploads/efa029460a62b62cbcff464af7cdb72a/vWin.log) + diff --git a/results/classifier/118/graphic/2933 b/results/classifier/118/graphic/2933 new file mode 100644 index 000000000..be8d0ab51 --- /dev/null +++ b/results/classifier/118/graphic/2933 @@ -0,0 +1,52 @@ +graphic: 0.947 +kernel: 0.831 +boot: 0.802 +device: 0.694 +performance: 0.616 +debug: 0.616 +user-level: 0.582 +socket: 0.577 +files: 0.570 +semantic: 0.540 +architecture: 0.524 +PID: 0.514 +ppc: 0.489 +vnc: 0.471 +network: 0.443 +mistranslation: 0.400 +x86: 0.400 +hypervisor: 0.380 +i386: 0.356 +permissions: 0.326 +register: 0.322 +risc-v: 0.315 +arm: 0.261 +KVM: 0.241 +VMM: 0.236 +TCG: 0.226 +assembly: 0.222 +virtual: 0.212 +peripherals: 0.158 + +After updating QEMU to 10.0, XNU kernel of OS X 10.8 throws kernel panic (type=0 divide error) +Description of problem: +Before updating to QEMU 10.0, my OS X 10.8 installation has worked pretty clear, but after QEMU update, XNU kernel now throws divide error during the boot. +Steps to reproduce: +1. Install OS X 10.8 on QEMU <10.0, for example 9.2.3. +2. Update QEMU to 10.0 version +3. Launch OS X +Additional information: +Screenshot of the issue: + + +OpenCore config (not changed before update, so above suspicion): +[config.plist](/uploads/4b80b60f9497e5ecd9237e4eeddcce8a/config.plist) + +Full OS X folder (without Installer.dmg): +[OS_X_10.8.zip](/uploads/1af6150869495a8f196e18d18127011b/OS_X_10.8.zip) + +How I've done Installer.dmg: +1. Go [here](https://updates.cdn-apple.com/2021/macos/031-0627-20210614-90D11F33-1A65-42DD-BBEA-E1D9F43A6B3F/InstallMacOSX.dmg) +2. `xar -xf` to .pkg +3. Show package contents to extracted .pkg +4. Here it is: InstallESD.dmg, which I've renamed to Installer.dmg diff --git a/results/classifier/118/graphic/2935 b/results/classifier/118/graphic/2935 new file mode 100644 index 000000000..45d2bf606 --- /dev/null +++ b/results/classifier/118/graphic/2935 @@ -0,0 +1,54 @@ +graphic: 0.824 +device: 0.780 +performance: 0.718 +files: 0.715 +architecture: 0.698 +semantic: 0.667 +PID: 0.637 +register: 0.582 +ppc: 0.557 +socket: 0.537 +vnc: 0.534 +arm: 0.520 +mistranslation: 0.497 +risc-v: 0.487 +network: 0.483 +boot: 0.479 +permissions: 0.477 +debug: 0.471 +peripherals: 0.459 +user-level: 0.455 +hypervisor: 0.443 +i386: 0.424 +kernel: 0.412 +TCG: 0.374 +VMM: 0.335 +KVM: 0.319 +virtual: 0.295 +x86: 0.291 +assembly: 0.253 + +strchrnul detection not suitable for macOS +Description of problem: +When qemu is compiled on macOS 15.4, targeting an earlier macOS version (e.g., 15.1), and then run on this earlier macOS version (15.1), it segfaults. This is because: + +- the meson test for strchrnul succeeds (the function is present in the library) +- the strchrnul function is therefore used +- but that function was introduced in the system's libc in 15.4 only + +The root cause for the bug is that the meson test for strchrnul does not include the appropriate header. Indeed, see the documentation for meson on compiler.has_function (https://mesonbuild.com/Compiler-properties.html#does-a-function-exist) + +> Note that, on macOS programs can be compiled targeting older macOS versions than the one that the program is compiled on. It can't be assumed that the OS version that is compiled on matches the OS version that the binary will run on. +> +> Therefore when detecting function availability with compiler.has_function(), it is important to specify the correct header in the prefix argument. + +The correct fix would be, in qemu's meson.build, to change: + +`cc.has_function('strchrnul')` + +into `cc.has_function('strchrnul', prefix : '#include <string>')` + +This is the recommended best practice and would allow correct detection on all platforms, including macOS. +Steps to reproduce: +1. Install qemu from Homebrew, which is built on macOS 15.4 +2. Run it on a machine with macOS < 15.4 diff --git a/results/classifier/118/graphic/2938 b/results/classifier/118/graphic/2938 new file mode 100644 index 000000000..417821e93 --- /dev/null +++ b/results/classifier/118/graphic/2938 @@ -0,0 +1,41 @@ +x86: 0.988 +graphic: 0.965 +kernel: 0.961 +architecture: 0.955 +device: 0.916 +boot: 0.907 +performance: 0.847 +PID: 0.765 +hypervisor: 0.747 +risc-v: 0.738 +vnc: 0.710 +register: 0.706 +arm: 0.703 +debug: 0.696 +network: 0.669 +socket: 0.665 +semantic: 0.664 +mistranslation: 0.574 +files: 0.568 +ppc: 0.561 +VMM: 0.528 +user-level: 0.441 +virtual: 0.423 +TCG: 0.418 +permissions: 0.368 +i386: 0.356 +assembly: 0.180 +peripherals: 0.101 +KVM: 0.077 + +10.0.0 HVF x86_64 regression: can't boot NetBSD 10.1 with -smp 2 +Description of problem: +Under 9.2.3, a NetBSD/amd64 10.1 guest with `-smp 2` booted and ran fine. + +Under 10.0.0, the same guest never finishes loading the kernel. It looks like it's retrying many times per second, possibly even reloading the NetBSD boot loader each time, though it's redrawing so fast I can't tell for sure. (I'll attempt to link to an asciinema capture shortly.) `-smp 1` lets the machine come up. + +For comparison, a NetBSD/aarch64 10.1 with `-smp 4` runs with `-accel hvf` under macOS/aarch64 15.4.1 just as well with 10.0.0 as it did with 9.2.3. +Steps to reproduce: +1. With x86 macOS host and NetBSD guest (possibly a wider range than the exact versions I'm currently using), attempt to boot NetBSD with `-smp 2` +Additional information: + diff --git a/results/classifier/118/graphic/2945 b/results/classifier/118/graphic/2945 new file mode 100644 index 000000000..9144095d6 --- /dev/null +++ b/results/classifier/118/graphic/2945 @@ -0,0 +1,59 @@ +graphic: 0.942 +device: 0.915 +PID: 0.888 +ppc: 0.885 +risc-v: 0.874 +architecture: 0.866 +user-level: 0.861 +performance: 0.852 +vnc: 0.835 +permissions: 0.834 +debug: 0.821 +kernel: 0.815 +boot: 0.806 +hypervisor: 0.769 +socket: 0.769 +peripherals: 0.766 +semantic: 0.764 +files: 0.759 +network: 0.725 +VMM: 0.722 +register: 0.709 +TCG: 0.697 +mistranslation: 0.662 +x86: 0.654 +arm: 0.585 +i386: 0.584 +virtual: 0.441 +KVM: 0.381 +assembly: 0.319 + +Commit da954d0e introduces a regression on sifive_unleashed when booting from SD card +Description of problem: +In U-Boot CI, we started to update from v8.2.0 to v9.2.3 and found that the sifive_unleashed target was failing to boot from SD card in our tests (we also test via SPI and this is fine). I have bisected the problem down to commit [da954d0e ("hw/sd/sdcard: Add spi_cmd_SEND_CSD/CID handlers (CMD9 & CMD10)")](https://gitlab.com/qemu-project/qemu/-/commit/da954d0e32444f122a41c24948d4d1c718bf66d4). + +When running QEMU we see the following output in the failure case as the only output: +``` +U-Boot SPL 2025.07-rc1-00033-gad60d9792896 (May 01 2025 - 17:08:34 +0000) +Trying to boot from MMC1 +spl: mmc init failed with error: -110 +Error: -110 +SPL: failed to boot from all boot devices +# +Steps to reproduce: +1. wget -O - https://github.com/pengutronix/genimage/releases/download/v14/genimage-14.tar.xz | tar -C /tmp -xJ ; cd /tmp/genimage-14 +2. ./configure && make -j$(nproc) +3. git clone https://source.denx.de/u-boot/u-boot.git; cd u-boot +4. wget -O - https://github.com/riscv-software-src/opensbi/releases/download/v1.3.1/opensbi-1.3.1-rv-bin.tar.xz | tar -C /tmp -xJ +5. export OPENSBI=/tmp/opensbi-1.3.1-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin +6. make O=/tmp/sifive_unleashed CROSS_COMPILE=riscv64-linux- sifive_unleashed_defconfig +7. make O=/tmp/sifive_unleashed CROSS_COMPILE=riscv64-linux- -sj$(nproc) +8. mkdir -p root +9. cp /tmp/sifive_unleashed/spl/u-boot-spl.bin . +10. cp /tmp/sifive_unleashed/u-boot.itb . +11. rm -rf tmp +12. genimage --inputpath . --config board/sifive/unleashed/genimage_sdcard.cfg +13. cp images/sdcard.img /tmp/sifive_unleashed/ +14. qemu-system-riscv64 -smp 5 -m 8G -nographic -M sifive_u,msel=11 -bios /tmp/sifive_unleashed/spl/u-boot-spl.bin -drive file=/tmp/sifive_unleashed/sdcard.img,format=raw,if=sd +Additional information: +The genimage tool is required for making the disk images used here. If building everything here is too much, I can provide the U-Boot binaries needed here out of band. diff --git a/results/classifier/118/graphic/2947 b/results/classifier/118/graphic/2947 new file mode 100644 index 000000000..a2b0b223c --- /dev/null +++ b/results/classifier/118/graphic/2947 @@ -0,0 +1,40 @@ +architecture: 0.995 +graphic: 0.962 +device: 0.866 +peripherals: 0.857 +arm: 0.842 +semantic: 0.753 +performance: 0.718 +boot: 0.659 +network: 0.627 +PID: 0.624 +mistranslation: 0.606 +user-level: 0.588 +debug: 0.537 +permissions: 0.531 +register: 0.511 +vnc: 0.434 +files: 0.426 +i386: 0.402 +x86: 0.395 +assembly: 0.371 +ppc: 0.353 +hypervisor: 0.345 +virtual: 0.297 +TCG: 0.294 +socket: 0.262 +risc-v: 0.256 +kernel: 0.230 +VMM: 0.205 +KVM: 0.046 + +Tablet-like mouse under Linux guest even if no -device usb-tablet is specified +Description of problem: +Arch Linux guest has absolute mouse tracking even when there is `-nodefaults` and no -device usb-tablet is provided. The guest does not have qemu guest agent installed. This is the unwanted behavior. The expected behavior is that it has a separate mouse pointer under guest, like with Windows guest. +Steps to reproduce: +1. Install guest operating system +2. Install gnome metapackage and enable GDM +3. Reboot +4. GDM has absolute mouse tracking and the mouse gets captured automatically, without having to click on the window or pressing Ctrl+Alt+G +Additional information: +[journalctl](/uploads/356952b8e2454c98e76ad82b700c518e/journalctl) diff --git a/results/classifier/118/graphic/2960 b/results/classifier/118/graphic/2960 new file mode 100644 index 000000000..ead330592 --- /dev/null +++ b/results/classifier/118/graphic/2960 @@ -0,0 +1,40 @@ +graphic: 0.985 +device: 0.861 +performance: 0.820 +peripherals: 0.652 +PID: 0.597 +VMM: 0.571 +virtual: 0.519 +socket: 0.484 +arm: 0.481 +debug: 0.470 +vnc: 0.462 +boot: 0.444 +mistranslation: 0.407 +semantic: 0.399 +risc-v: 0.344 +architecture: 0.328 +register: 0.279 +TCG: 0.228 +i386: 0.226 +files: 0.216 +ppc: 0.210 +permissions: 0.176 +x86: 0.163 +network: 0.152 +user-level: 0.140 +KVM: 0.112 +kernel: 0.098 +assembly: 0.054 +hypervisor: 0.035 + +Mouse doesn't work correctly with SDL display backend +Description of problem: +The mouse starts moving like crazy, up and down or left and right. +I tested it with -accel on and off, I make some test and seems to be the SDL display backed(GTK just crash before start execution of the vm). +Steps to reproduce: +1.Install Linux Mint 22.1 +2.Execute the command above. +3.Log in and the problems start. +Additional information: + diff --git a/results/classifier/118/graphic/2962 b/results/classifier/118/graphic/2962 new file mode 100644 index 000000000..89c7cc2f2 --- /dev/null +++ b/results/classifier/118/graphic/2962 @@ -0,0 +1,52 @@ +graphic: 0.983 +assembly: 0.955 +device: 0.948 +boot: 0.936 +architecture: 0.901 +PID: 0.899 +files: 0.894 +network: 0.887 +ppc: 0.885 +x86: 0.862 +peripherals: 0.861 +kernel: 0.850 +performance: 0.848 +virtual: 0.803 +vnc: 0.797 +user-level: 0.797 +permissions: 0.794 +debug: 0.793 +socket: 0.779 +hypervisor: 0.737 +i386: 0.735 +register: 0.732 +mistranslation: 0.686 +semantic: 0.664 +KVM: 0.608 +TCG: 0.581 +risc-v: 0.556 +VMM: 0.529 +arm: 0.379 + +DHCP UDP checksum workaround code appears to be broken +Description of problem: +I am running dnsmasq DHCP server in an lxc-container. It is using a VETH pair for the network. The VETH device on the host is in a bridge. I create a TAP device and place it in the bridge. When booting the guest, I notice that the DHCP OFFER has an invalid UDP checksum all the way through the bridge and into the guest. I am able to fix this by disabling checksum offload inside the container, or adding an nftables rule that zeros out the checksum, or by reverting commit 7987d2be5a8bc3a502f89ba8cf3ac3e09f64d1ce. +Steps to reproduce: +1. From a debian 12 host, `apt-get install lxc lxc-templates` +2. `ip link add brtest type bridge` +3. `ip link set brtest up` +4. Create a container: `lxc-create -n dhcp -t debian -- --package=dnsmasq` +5. Edit the lxc container file `/var/lib/lxc/dhcp/config` and make sure the link is properly set to `lxc.net.0.link = brtest`, the type is set to `veth`, and give it an IP `lxc.net.0.ipv4.address = 192.168.255.1/24` +6. Start the container: `lxc-start -n dhcp` +7. Attach to the container: `lxc-attach -n dhcp` +8. Stop dnsmasq and networking: `systemctl stop dnsmasq.service networking.service` +9. Run a DHCP server: `dnsmasq --dhcp-authoritative --dhcp-range=192.168.255.2,192.168.255.254,255.255.255.0,1h --dns-loop-detect` +10. Exit the container: `exit` +11. Download the linux mint 22.1 installer: https://linuxmint.com/edition.php?id=319 +12. Create a TAP device and throw it in the bridge: `ip tuntap add dev taptest mode tap` .. `ip link set dev taptest up master brtest` +13. Run qemu: `qemu-system-x86_64 -enable-kvm -smp 4,sockets=1,threads=1 -machine pc-q35-9.2,accel=kvm,kernel_irqchip=on -m 4096 -device virtio-net-pci,netdev=nic91 -netdev tap,id=nic91,ifname=taptest,script=no,downscript=no -cdrom linuxmint-22.1-cinnamon-64bit.iso` .. I run it with vnc as this is on a headless server. +14. Once the guest has booted, you can run a tcpdump on the NIC and see that the guest receives the DHCP offer, but the UDP checksum is bunk. +Additional information: +I was able to test reverting the commit 7987d2be5a8bc3a502f89ba8cf3ac3e09f64d1ce and that appears to function once again. + +{width=901 height=38} diff --git a/results/classifier/118/graphic/2965 b/results/classifier/118/graphic/2965 new file mode 100644 index 000000000..f7ed18a7e --- /dev/null +++ b/results/classifier/118/graphic/2965 @@ -0,0 +1,44 @@ +graphic: 0.895 +permissions: 0.893 +device: 0.879 +x86: 0.859 +PID: 0.743 +semantic: 0.723 +vnc: 0.706 +architecture: 0.669 +debug: 0.656 +files: 0.625 +socket: 0.546 +register: 0.531 +boot: 0.524 +ppc: 0.496 +risc-v: 0.452 +VMM: 0.442 +performance: 0.433 +network: 0.399 +kernel: 0.375 +arm: 0.368 +TCG: 0.352 +mistranslation: 0.283 +user-level: 0.205 +hypervisor: 0.139 +i386: 0.120 +peripherals: 0.088 +virtual: 0.074 +assembly: 0.060 +KVM: 0.031 + +crash when interacting with the UI in any way during record/replay mode on macOS +Description of problem: +``` +** +ERROR:../replay/replay-events.c:119:replay_add_event: assertion failed: (replay_mutex_locked()) +Bail out! ERROR:../replay/replay-events.c:119:replay_add_event: assertion failed: (replay_mutex_locked()) +fish: Job 1, 'qemu-system-x86_64 -icount shif…' terminated by signal SIGABRT (Abort) +``` +Steps to reproduce: +1. run the qemu command +2. click in the window +3. observe crash +Additional information: +[qemu-system-x86_64-2025-05-15-032037.ips](/uploads/2cccc7b967dacc8a18be8a3d0a0cf297/qemu-system-x86_64-2025-05-15-032037.ips) diff --git a/results/classifier/118/graphic/2966 b/results/classifier/118/graphic/2966 new file mode 100644 index 000000000..1077b6b25 --- /dev/null +++ b/results/classifier/118/graphic/2966 @@ -0,0 +1,57 @@ +graphic: 0.983 +KVM: 0.981 +device: 0.861 +ppc: 0.801 +semantic: 0.769 +kernel: 0.759 +permissions: 0.748 +boot: 0.740 +PID: 0.737 +architecture: 0.618 +risc-v: 0.614 +hypervisor: 0.598 +VMM: 0.590 +user-level: 0.585 +vnc: 0.582 +socket: 0.578 +arm: 0.574 +performance: 0.560 +assembly: 0.545 +network: 0.544 +TCG: 0.542 +files: 0.514 +register: 0.498 +x86: 0.497 +debug: 0.477 +mistranslation: 0.471 +i386: 0.449 +virtual: 0.439 +peripherals: 0.389 + +KVM: Failed to create TCE64 table for liobn 0x80000001 +Description of problem: +When rebooting the system we hit : + ``` + KVM: Failed to create TCE64 table for liobn 0x80000001 + qemu-system-ppc64: ../system/memory.c:2666: memory_region_add_subregion_common: Assertion `!subregion->container' failed. + Aborted (core dumped) + ``` +Steps to reproduce: +1. Start the machine +2. Reboot it + + ``` + curl -LO https://cloud.centos.org/centos/10-stream/ppc64le/images/CentOS-Stream-GenericCloud-10-20250512.0.ppc64le.qcow2 + export LIBGUESTFS_BACKEND=direct + virt-customize -v -a CentOS-Stream-GenericCloud-10-20250512.0.ppc64le.qcow2 --root-password password:centos + qemu-system-ppc64 --enable-kvm -m 4096 -smp 8 -hda CentOS-Stream-GenericCloud-10-20250512.0.ppc64le.qcow2 -vga none -nographic -device qemu-xhci + # once logged into it + systemctl reboot + [...] + KVM: Failed to create TCE64 table for liobn 0x80000001 + qemu-system-ppc64: ../system/memory.c:2666: memory_region_add_subregion_common: Assertion `!subregion->container' failed. + Aborted (core dumped) + ``` +Additional information: +The issue was already reported on ML https://lists.nongnu.org/archive/html/qemu-devel/2025-03/msg05137.html +I also hit that issue while building a CoreOS CentOS Stream 10 image https://github.com/openshift/os/issues/1818. I was able to validate that the commit https://github.com/torvalds/linux/commit/6aa989ab2bd0d37540c812b4270006ff794662e7 introduced the bug. diff --git a/results/classifier/118/graphic/2973 b/results/classifier/118/graphic/2973 new file mode 100644 index 000000000..a805a1226 --- /dev/null +++ b/results/classifier/118/graphic/2973 @@ -0,0 +1,93 @@ +graphic: 0.962 +device: 0.903 +debug: 0.900 +hypervisor: 0.887 +boot: 0.886 +performance: 0.863 +user-level: 0.827 +kernel: 0.814 +architecture: 0.741 +risc-v: 0.740 +mistranslation: 0.716 +ppc: 0.699 +vnc: 0.691 +semantic: 0.677 +arm: 0.650 +socket: 0.635 +PID: 0.623 +VMM: 0.574 +x86: 0.530 +permissions: 0.498 +register: 0.484 +network: 0.445 +assembly: 0.442 +TCG: 0.397 +KVM: 0.380 +files: 0.344 +peripherals: 0.329 +i386: 0.326 +virtual: 0.280 + +ast2700a0-evb machine hangs in U-Boot when trying to determine the RAM size +Description of problem: +On a BE host, the ast2700a0-evb machine hangs in U-Boot when trying to determine the RAM size if the RAM size is set to a value other than 8 GB. +Steps to reproduce: +1. ./qemu-system-aarch64 -machine ast2700a0-evb -m 1g +2. +3. +Additional information: +On a BE host, if I run an ast2700a0-evb machine : + ``` + $ qemu-system-aarch64 -machine ast2700a0-evb ... + ... + U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000) + + SOC: AST2700-A0 + Model: AST2700 EVB + DRAM: 8 GiB (effective 0 Bytes) + ``` + +QEMU hangs. + +If the RAM size is defined to 8g + ``` + $ qemu-system-aarch64 -machine ast2700a0-evb -m 8g ... + ... + U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000) + + SOC: AST2700-A0 + Model: AST2700 EVB + DRAM: 8 GiB + aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp. version(0) + Core: 125 devices, 27 uclasses, devicetree: separate + ``` + +machine boots. + +Whereas, with an ast2700a1-evb machine : + ``` + $ qemu-system-aarch64 -machine ast2700a1-evb ... + ... + U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000) + + SOC: AST2700-A1 + Model: AST2700 EVB + DRAM: 1 GiB + aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp. version(0) + Core: 125 devices, 27 uclasses, devicetree: separate + ``` + +machine boots. + ``` + $ qemu-system-aarch64 -machine ast2700a1-evb -m 8g ... + ... + U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000) + + SOC: AST2700-A1 + Model: AST2700 EVB + DRAM: 8 GiB + aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp. version(0) + Core: 125 devices, 27 uclasses, devicetree: separate + ``` + +machine boots. diff --git a/results/classifier/118/graphic/2981 b/results/classifier/118/graphic/2981 new file mode 100644 index 000000000..9e580248c --- /dev/null +++ b/results/classifier/118/graphic/2981 @@ -0,0 +1,55 @@ +architecture: 0.963 +graphic: 0.937 +arm: 0.874 +debug: 0.854 +performance: 0.807 +virtual: 0.769 +device: 0.747 +semantic: 0.712 +kernel: 0.703 +peripherals: 0.566 +user-level: 0.564 +TCG: 0.531 +PID: 0.441 +hypervisor: 0.417 +boot: 0.407 +files: 0.383 +register: 0.307 +ppc: 0.281 +risc-v: 0.255 +mistranslation: 0.196 +permissions: 0.173 +VMM: 0.168 +network: 0.148 +assembly: 0.141 +vnc: 0.137 +socket: 0.065 +x86: 0.020 +i386: 0.005 +KVM: 0.003 + +Assert error with accel=hvf:tcg when hvf is unavailable +Description of problem: +Trying to start qemu with `-machine virt,accel=hvf:tcg` in a Mac OS guest under Mac OS host, both arm64. I expect it to try hvf (unavailable - nested virtualization not supported) and fallback to tcg. Documentation for accel option says "If there is more than one accelerator specified, the next one is used if the previous one fails to initialize." This works fine with kvm, but for hvf it crashes in some auxiliary function when trying it: + +``` +% qemu-system-aarch64 -machine virt,accel=hvf:tcg +qemu-system-aarch64: Error: ret = HV_UNSUPPORTED (0xfae9400f, at ../target/arm/hvf/hvf.c:949) +``` + +Stack trace +``` + * frame #0: 0x0000000193a18388 libsystem_kernel.dylib`__pthread_kill + 8 + frame #1: 0x0000000193a5188c libsystem_pthread.dylib`pthread_kill + 296 + frame #2: 0x000000019395ac60 libsystem_c.dylib`abort + 124 + frame #3: 0x00000001005ee7f4 qemu-system-aarch64`assert_hvf_ok_impl + 92 + frame #4: 0x000000010032a550 qemu-system-aarch64`hvf_arm_get_max_ipa_bit_size + 64 + frame #5: 0x0000000100334928 qemu-system-aarch64`virt_hvf_get_physical_address_range + 68 + frame #6: 0x00000001005ee9b8 qemu-system-aarch64`hvf_accel_init + 68 + frame #7: 0x00000001002ef8e4 qemu-system-aarch64`accel_init_machine + 92 + frame #8: 0x00000001002a6640 qemu-system-aarch64`do_configure_accelerator + 208 + frame #9: 0x0000000100782bdc qemu-system-aarch64`qemu_opts_foreach + 112 + frame #10: 0x00000001002a3180 qemu-system-aarch64`qemu_init + 11344 + frame #11: 0x00000001006ea76c qemu-system-aarch64`main + 36 + frame #12: 0x00000001936b2b4c dyld`start + 6000 +``` diff --git a/results/classifier/118/graphic/2987 b/results/classifier/118/graphic/2987 new file mode 100644 index 000000000..389d88980 --- /dev/null +++ b/results/classifier/118/graphic/2987 @@ -0,0 +1,37 @@ +TCG: 0.989 +graphic: 0.970 +debug: 0.953 +device: 0.944 +boot: 0.941 +network: 0.858 +vnc: 0.844 +performance: 0.840 +files: 0.821 +architecture: 0.817 +PID: 0.792 +kernel: 0.785 +VMM: 0.784 +risc-v: 0.741 +semantic: 0.734 +socket: 0.719 +register: 0.697 +ppc: 0.696 +mistranslation: 0.654 +permissions: 0.635 +hypervisor: 0.602 +arm: 0.595 +x86: 0.568 +i386: 0.532 +peripherals: 0.438 +KVM: 0.412 +user-level: 0.356 +assembly: 0.340 +virtual: 0.268 + +QEMU TCG failed to boot Windows 98 Second Edition +Description of problem: +QEMU TCG failed at booting Windows 98 Second Edition 4.10.2222B. + +Bisected to commit e54ef98c8a80d16158bab4341d9a898701270528 +Additional information: + diff --git a/results/classifier/118/graphic/30680944 b/results/classifier/118/graphic/30680944 new file mode 100644 index 000000000..2b4e70a8a --- /dev/null +++ b/results/classifier/118/graphic/30680944 @@ -0,0 +1,620 @@ +graphic: 0.965 +semantic: 0.953 +register: 0.941 +assembly: 0.940 +performance: 0.937 +debug: 0.936 +device: 0.935 +permissions: 0.933 +virtual: 0.932 +architecture: 0.927 +PID: 0.913 +arm: 0.910 +hypervisor: 0.909 +kernel: 0.878 +socket: 0.864 +peripherals: 0.850 +VMM: 0.846 +boot: 0.840 +files: 0.835 +risc-v: 0.830 +TCG: 0.828 +user-level: 0.827 +vnc: 0.815 +network: 0.813 +mistranslation: 0.799 +ppc: 0.762 +i386: 0.716 +KVM: 0.701 +x86: 0.661 + +[BUG]QEMU jump into interrupt when single-stepping on aarch64 + +Dear, folks, + +I try to debug Linux kernel with QEMU in single-stepping mode on aarch64 +platform, +the added breakpoint hits but after I type `step`, the gdb always jumps into +interrupt. + +My env: + + gdb-10.2 + qemu-6.2.0 + host kernel: 5.10.84 + VM kernel: 5.10.84 + +The steps to reproduce: + # host console: run a VM with only one core, the import arg: <qemu:arg +value='-s'/> + # details can be found here: +https://www.redhat.com/en/blog/debugging-kernel-qemulibvirt +virsh create dev_core0.xml + + # run gdb client + gdb ./vmlinux + + # gdb client on host console + (gdb) dir +./usr/src/debug/kernel-5.10.84/linux-5.10.84-004.alpha.ali5000.alios7.aarch64 + (gdb) target remote localhost:1234 + (gdb) info b + Num Type Disp Enb Address What + 1 breakpoint keep y <MULTIPLE> + 1.1 y 0xffff800010361444 +mm/memory-failure.c:1318 + 1.2 y 0xffff800010361450 in memory_failure + at mm/memory-failure.c:1488 + (gdb) c + Continuing. + + # console in VM, use madvise to inject a hwposion at virtual address +vaddr, + # which will hit the b inmemory_failur: madvise(vaddr, pagesize, +MADV_HWPOISON); + # and the VM pause + ./run_madvise.c + + # gdb client on host console + (gdb) + Continuing. + Breakpoint 1, 0xffff800010361444 in memory_failure () at +mm/memory-failure.c:1318 + 1318 res = -EHWPOISON; + (gdb) n + vectors () at arch/arm64/kernel/entry.S:552 + 552 kernel_ventry 1, irq // IRQ +EL1h + (gdb) n + (gdb) n + (gdb) n + (gdb) n + gic_handle_irq (regs=0xffff8000147c3b80) at +drivers/irqchip/irq-gic-v3.c:721 + # after several step, I got the irqnr + (gdb) p irqnr + $5 = 8262 + +Sometimes, the irqnr is 27ï¼ which is used for arch_timer. + +I was wondering do you have any comments on this? And feedback are welcomed. + +Thank you. + +Best Regards. +Shuai + +On 4/6/22 09:30, Shuai Xue wrote: +Dear, folks, + +I try to debug Linux kernel with QEMU in single-stepping mode on aarch64 +platform, +the added breakpoint hits but after I type `step`, the gdb always jumps into +interrupt. + +My env: + + gdb-10.2 + qemu-6.2.0 + host kernel: 5.10.84 + VM kernel: 5.10.84 + +The steps to reproduce: + # host console: run a VM with only one core, the import arg: <qemu:arg +value='-s'/> + # details can be found here: +https://www.redhat.com/en/blog/debugging-kernel-qemulibvirt +virsh create dev_core0.xml + + # run gdb client + gdb ./vmlinux + + # gdb client on host console + (gdb) dir +./usr/src/debug/kernel-5.10.84/linux-5.10.84-004.alpha.ali5000.alios7.aarch64 + (gdb) target remote localhost:1234 + (gdb) info b + Num Type Disp Enb Address What + 1 breakpoint keep y <MULTIPLE> + 1.1 y 0xffff800010361444 +mm/memory-failure.c:1318 + 1.2 y 0xffff800010361450 in memory_failure + at mm/memory-failure.c:1488 + (gdb) c + Continuing. + + # console in VM, use madvise to inject a hwposion at virtual address +vaddr, + # which will hit the b inmemory_failur: madvise(vaddr, pagesize, +MADV_HWPOISON); + # and the VM pause + ./run_madvise.c + + # gdb client on host console + (gdb) + Continuing. + Breakpoint 1, 0xffff800010361444 in memory_failure () at +mm/memory-failure.c:1318 + 1318 res = -EHWPOISON; + (gdb) n + vectors () at arch/arm64/kernel/entry.S:552 + 552 kernel_ventry 1, irq // IRQ +EL1h +The 'n' command is not a single-step: use stepi, which will suppress interrupts. +Anyway, not a bug. + +r~ + +å¨ 2022/4/7 AM12:57, Richard Henderson åé: +> +On 4/6/22 09:30, Shuai Xue wrote: +> +> Dear, folks, +> +> +> +> I try to debug Linux kernel with QEMU in single-stepping mode on aarch64 +> +> platform, +> +> the added breakpoint hits but after I type `step`, the gdb always jumps into +> +> interrupt. +> +> +> +> My env: +> +> +> +>     gdb-10.2 +> +>     qemu-6.2.0 +> +>     host kernel: 5.10.84 +> +>     VM kernel: 5.10.84 +> +> +> +> The steps to reproduce: +> +>     # host console: run a VM with only one core, the import arg: <qemu:arg +> +> value='-s'/> +> +>     # details can be found here: +> +> +https://www.redhat.com/en/blog/debugging-kernel-qemulibvirt +> +>     virsh create dev_core0.xml +> +>     +> +>     # run gdb client +> +>     gdb ./vmlinux +> +> +> +>     # gdb client on host console +> +>     (gdb) dir +> +> ./usr/src/debug/kernel-5.10.84/linux-5.10.84-004.alpha.ali5000.alios7.aarch64 +> +>     (gdb) target remote localhost:1234 +> +>     (gdb) info b +> +>     Num    Type          Disp Enb Address           What +> +>     1      breakpoint    keep y  <MULTIPLE> +> +>     1.1                        y  0xffff800010361444 +> +> mm/memory-failure.c:1318 +> +>     1.2                        y  0xffff800010361450 in memory_failure +> +>                                                    at +> +> mm/memory-failure.c:1488 +> +>     (gdb) c +> +>     Continuing. +> +> +> +>     # console in VM, use madvise to inject a hwposion at virtual address +> +> vaddr, +> +>     # which will hit the b inmemory_failur: madvise(vaddr, pagesize, +> +> MADV_HWPOISON); +> +>     # and the VM pause +> +>     ./run_madvise.c +> +> +> +>     # gdb client on host console +> +>     (gdb) +> +>     Continuing. +> +>     Breakpoint 1, 0xffff800010361444 in memory_failure () at +> +> mm/memory-failure.c:1318 +> +>     1318                   res = -EHWPOISON; +> +>     (gdb) n +> +>     vectors () at arch/arm64/kernel/entry.S:552 +> +>     552            kernel_ventry  1, irq                         // IRQ +> +> EL1h +> +> +The 'n' command is not a single-step: use stepi, which will suppress +> +interrupts. +> +Anyway, not a bug. +> +> +r~ +Hi, Richard, + +Thank you for your quick reply, I also try `stepi`, but it does NOT work either. + + (gdb) c + Continuing. + + Breakpoint 1, memory_failure (pfn=1273982, flags=1) at +mm/memory-failure.c:1488 + 1488 { + (gdb) stepi + vectors () at arch/arm64/kernel/entry.S:552 + 552 kernel_ventry 1, irq // IRQ +EL1h + +According to QEMU doc[1]: the default single stepping behavior is step with the +IRQs +and timer service routines off. I checked the MASK bits used to control the +single +stepping IE on my machine as bellow: + + # gdb client on host (x86 plafrom) + (gdb) maintenance packet qqemu.sstepbits + sending: "qqemu.sstepbits" + received: "ENABLE=1,NOIRQ=2,NOTIMER=4" + +The sstep MASK looks as expected, but does not work as expected. + +I also try the same kernel and qemu version on X86 platform: +> +> gdb-10.2 +> +> qemu-6.2.0 +> +> host kernel: 5.10.84 +> +> VM kernel: 5.10.84 +The command `n` jumps to the next instruction. + + # gdb client on host (x86 plafrom) + (gdb) b memory-failure.c:1488 + Breakpoint 1, memory_failure (pfn=1128931, flags=1) at +mm/memory-failure.c:1488 + 1488 { + (gdb) n + 1497 if (!sysctl_memory_failure_recovery) + (gdb) stepi + 0xffffffff812efdbc 1497 if +(!sysctl_memory_failure_recovery) + (gdb) stepi + 0xffffffff812efdbe 1497 if +(!sysctl_memory_failure_recovery) + (gdb) n + 1500 p = pfn_to_online_page(pfn); + (gdb) l + 1496 + 1497 if (!sysctl_memory_failure_recovery) + 1498 panic("Memory failure on page %lx", pfn); + 1499 + 1500 p = pfn_to_online_page(pfn); + 1501 if (!p) { + +Best Regrades, +Shuai + + +[1] +https://github.com/qemu/qemu/blob/master/docs/system/gdb.rst + +å¨ 2022/4/7 PM12:10, Shuai Xue åé: +> +å¨ 2022/4/7 AM12:57, Richard Henderson åé: +> +> On 4/6/22 09:30, Shuai Xue wrote: +> +>> Dear, folks, +> +>> +> +>> I try to debug Linux kernel with QEMU in single-stepping mode on aarch64 +> +>> platform, +> +>> the added breakpoint hits but after I type `step`, the gdb always jumps +> +>> into interrupt. +> +>> +> +>> My env: +> +>> +> +>>     gdb-10.2 +> +>>     qemu-6.2.0 +> +>>     host kernel: 5.10.84 +> +>>     VM kernel: 5.10.84 +> +>> +> +>> The steps to reproduce: +> +>>     # host console: run a VM with only one core, the import arg: <qemu:arg +> +>> value='-s'/> +> +>>     # details can be found here: +> +>> +https://www.redhat.com/en/blog/debugging-kernel-qemulibvirt +> +>>     virsh create dev_core0.xml +> +>>     +> +>>     # run gdb client +> +>>     gdb ./vmlinux +> +>> +> +>>     # gdb client on host console +> +>>     (gdb) dir +> +>> ./usr/src/debug/kernel-5.10.84/linux-5.10.84-004.alpha.ali5000.alios7.aarch64 +> +>>     (gdb) target remote localhost:1234 +> +>>     (gdb) info b +> +>>     Num    Type          Disp Enb Address           What +> +>>     1      breakpoint    keep y  <MULTIPLE> +> +>>     1.1                        y  0xffff800010361444 +> +>> mm/memory-failure.c:1318 +> +>>     1.2                        y  0xffff800010361450 in memory_failure +> +>>                                                    at +> +>> mm/memory-failure.c:1488 +> +>>     (gdb) c +> +>>     Continuing. +> +>> +> +>>     # console in VM, use madvise to inject a hwposion at virtual address +> +>> vaddr, +> +>>     # which will hit the b inmemory_failur: madvise(vaddr, pagesize, +> +>> MADV_HWPOISON); +> +>>     # and the VM pause +> +>>     ./run_madvise.c +> +>> +> +>>     # gdb client on host console +> +>>     (gdb) +> +>>     Continuing. +> +>>     Breakpoint 1, 0xffff800010361444 in memory_failure () at +> +>> mm/memory-failure.c:1318 +> +>>     1318                   res = -EHWPOISON; +> +>>     (gdb) n +> +>>     vectors () at arch/arm64/kernel/entry.S:552 +> +>>     552            kernel_ventry  1, irq                         // IRQ +> +>> EL1h +> +> +> +> The 'n' command is not a single-step: use stepi, which will suppress +> +> interrupts. +> +> Anyway, not a bug. +> +> +> +> r~ +> +> +Hi, Richard, +> +> +Thank you for your quick reply, I also try `stepi`, but it does NOT work +> +either. +> +> +(gdb) c +> +Continuing. +> +> +Breakpoint 1, memory_failure (pfn=1273982, flags=1) at +> +mm/memory-failure.c:1488 +> +1488 { +> +(gdb) stepi +> +vectors () at arch/arm64/kernel/entry.S:552 +> +552 kernel_ventry 1, irq // IRQ +> +EL1h +> +> +According to QEMU doc[1]: the default single stepping behavior is step with +> +the IRQs +> +and timer service routines off. I checked the MASK bits used to control the +> +single +> +stepping IE on my machine as bellow: +> +> +# gdb client on host (x86 plafrom) +> +(gdb) maintenance packet qqemu.sstepbits +> +sending: "qqemu.sstepbits" +> +received: "ENABLE=1,NOIRQ=2,NOTIMER=4" +> +> +The sstep MASK looks as expected, but does not work as expected. +> +> +I also try the same kernel and qemu version on X86 platform: +> +>> gdb-10.2 +> +>> qemu-6.2.0 +> +>> host kernel: 5.10.84 +> +>> VM kernel: 5.10.84 +> +> +> +The command `n` jumps to the next instruction. +> +> +# gdb client on host (x86 plafrom) +> +(gdb) b memory-failure.c:1488 +> +Breakpoint 1, memory_failure (pfn=1128931, flags=1) at +> +mm/memory-failure.c:1488 +> +1488 { +> +(gdb) n +> +1497 if (!sysctl_memory_failure_recovery) +> +(gdb) stepi +> +0xffffffff812efdbc 1497 if +> +(!sysctl_memory_failure_recovery) +> +(gdb) stepi +> +0xffffffff812efdbe 1497 if +> +(!sysctl_memory_failure_recovery) +> +(gdb) n +> +1500 p = pfn_to_online_page(pfn); +> +(gdb) l +> +1496 +> +1497 if (!sysctl_memory_failure_recovery) +> +1498 panic("Memory failure on page %lx", pfn); +> +1499 +> +1500 p = pfn_to_online_page(pfn); +> +1501 if (!p) { +> +> +Best Regrades, +> +Shuai +> +> +> +[1] +https://github.com/qemu/qemu/blob/master/docs/system/gdb.rst +Hi, Richard, + +I was wondering that do you have any comments to this? + +Best Regrades, +Shuai + diff --git a/results/classifier/118/graphic/322602 b/results/classifier/118/graphic/322602 new file mode 100644 index 000000000..8bf546e34 --- /dev/null +++ b/results/classifier/118/graphic/322602 @@ -0,0 +1,58 @@ +graphic: 0.899 +device: 0.726 +performance: 0.715 +virtual: 0.613 +semantic: 0.526 +user-level: 0.511 +architecture: 0.504 +socket: 0.444 +kernel: 0.421 +PID: 0.412 +mistranslation: 0.396 +permissions: 0.378 +assembly: 0.373 +vnc: 0.366 +boot: 0.360 +register: 0.349 +debug: 0.344 +network: 0.341 +ppc: 0.296 +i386: 0.275 +x86: 0.262 +hypervisor: 0.244 +files: 0.196 +VMM: 0.178 +risc-v: 0.177 +arm: 0.164 +TCG: 0.148 +peripherals: 0.128 +KVM: 0.126 + +Snapshot usage makes qcow2 image unusable due to large tables + +To reproduce with 0.9.1 and svn: +- Create a 20G (or some size much greater than system RAM) qcow2 image +- Inside VM, install some OS, formatting whole drive +- Create snapshot with savevm +- Inside VM, reformat and reinstall OS +- Create snapshot with savevm +[...] + +Eventually, qemu crashes, then neither qemu-img nor qemu can open the image because memory is exhausted. The reason is that the whole refcount_table is loaded into memory, and this refcount_table has now become much bigger than the size of memory. + +The refcount_table really needs to be loaded and used in fixed size chunks to avoid this problem. + +Alternatively, there needs to be a way to "rollback" a snapshot without loading the whole disk image normally, so that a snapshot which has made the image unusable in this way can be reversed. + +Hi, + +Could you please let us know whether this is still a problem and if it isn't, lets close this bug. + + In addition, you haven't listed which version of qemu-kvm you are running. I am guessing it is something Ubuntu based based on the version number, but since not all of us are running Ubuntu it would be useful to have more details. + +Thanks, +Jes + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/352 b/results/classifier/118/graphic/352 new file mode 100644 index 000000000..11b3a2eb0 --- /dev/null +++ b/results/classifier/118/graphic/352 @@ -0,0 +1,31 @@ +graphic: 0.955 +debug: 0.775 +device: 0.706 +risc-v: 0.508 +ppc: 0.402 +performance: 0.400 +boot: 0.381 +VMM: 0.362 +vnc: 0.310 +mistranslation: 0.276 +TCG: 0.255 +PID: 0.196 +peripherals: 0.170 +permissions: 0.160 +user-level: 0.135 +KVM: 0.132 +register: 0.121 +i386: 0.118 +arm: 0.115 +files: 0.102 +network: 0.095 +socket: 0.088 +kernel: 0.059 +hypervisor: 0.051 +x86: 0.046 +semantic: 0.040 +architecture: 0.038 +virtual: 0.030 +assembly: 0.007 + +audio input crack diff --git a/results/classifier/118/graphic/370 b/results/classifier/118/graphic/370 new file mode 100644 index 000000000..47ae29989 --- /dev/null +++ b/results/classifier/118/graphic/370 @@ -0,0 +1,31 @@ +graphic: 0.820 +device: 0.762 +peripherals: 0.664 +mistranslation: 0.537 +vnc: 0.444 +VMM: 0.344 +TCG: 0.341 +risc-v: 0.340 +PID: 0.319 +ppc: 0.303 +socket: 0.289 +i386: 0.285 +network: 0.267 +register: 0.256 +semantic: 0.240 +KVM: 0.237 +x86: 0.233 +boot: 0.230 +arm: 0.209 +permissions: 0.142 +files: 0.135 +virtual: 0.126 +performance: 0.118 +debug: 0.106 +hypervisor: 0.070 +user-level: 0.065 +kernel: 0.045 +architecture: 0.025 +assembly: 0.004 + +Indentation should be done with spaces, not with TABs, in the UI, graphics, audio and USB subsystem diff --git a/results/classifier/118/graphic/391879 b/results/classifier/118/graphic/391879 new file mode 100644 index 000000000..63877ceb9 --- /dev/null +++ b/results/classifier/118/graphic/391879 @@ -0,0 +1,71 @@ +graphic: 0.924 +semantic: 0.919 +KVM: 0.907 +performance: 0.901 +user-level: 0.869 +hypervisor: 0.863 +virtual: 0.840 +device: 0.833 +architecture: 0.833 +register: 0.832 +mistranslation: 0.832 +files: 0.830 +debug: 0.804 +network: 0.791 +ppc: 0.777 +permissions: 0.771 +VMM: 0.763 +i386: 0.727 +PID: 0.722 +x86: 0.717 +TCG: 0.698 +socket: 0.689 +vnc: 0.682 +peripherals: 0.673 +kernel: 0.644 +risc-v: 0.608 +boot: 0.590 +arm: 0.589 +assembly: 0.473 + +migrate exec ignores exit status + +Binary package hint: kvm + +Using + + migrate "exec:cat > foo; false" + +in the monitor results in the state of the VM being written to foo, as expected, and the VM then being stopped. This is surprising, as I think it stands to reason that in case of a failed migrate-exec process, which is what a non-zero exit status implies to me, the VM should continue. + +== Version information + +$ lsb_release -rd +Description: Ubuntu 9.04 +Release: 9.04 + +$ apt-cache policy kvm +kvm: + Installed: 1:84+dfsg-0ubuntu11 + Candidate: 1:84+dfsg-0ubuntu11 + Version table: + *** 1:84+dfsg-0ubuntu11 0 + 500 http://gb.archive.ubuntu.com jaunty/main Packages + 100 /var/lib/dpkg/status + +Well, I have reproduced this behavior in Lucid's qemu-kvm 0.12.3, so the report is still accurate. + +I don't have a strong opinion on the desired behavior, though I can certainly see the bug reporter's point. + +This bug is filed against the upstream QEMU project, so we'll defer to Upstream's decision on this feature. Thanks for the report. + +This is a bug and has been reported upstream, it is unlikely to be fixed at the distribution level and therefore anyone interested in working on this bug should contribute a patch to the upstream project. This will then filter down to Ubuntu when it is merged mainline. Marking "Won't Fix" against the Ubuntu package. + +Thanks for reporting this bug. + +The attached patch works for me with the posted test case. + +Patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=41ef56e61153d7bd27d34a63463 +So I assume this should be working now. + diff --git a/results/classifier/118/graphic/439 b/results/classifier/118/graphic/439 new file mode 100644 index 000000000..0ba3eeefe --- /dev/null +++ b/results/classifier/118/graphic/439 @@ -0,0 +1,31 @@ +graphic: 0.942 +device: 0.641 +performance: 0.406 +network: 0.359 +permissions: 0.306 +hypervisor: 0.278 +peripherals: 0.230 +files: 0.200 +debug: 0.195 +register: 0.173 +architecture: 0.162 +boot: 0.157 +user-level: 0.126 +semantic: 0.126 +mistranslation: 0.124 +PID: 0.120 +arm: 0.116 +virtual: 0.115 +vnc: 0.109 +x86: 0.098 +VMM: 0.085 +ppc: 0.082 +i386: 0.071 +socket: 0.064 +TCG: 0.054 +kernel: 0.031 +risc-v: 0.029 +assembly: 0.021 +KVM: 0.011 + +Hard crash - qemu-6.0.0 with windows 10 guest diff --git a/results/classifier/118/graphic/441672 b/results/classifier/118/graphic/441672 new file mode 100644 index 000000000..c9773eb19 --- /dev/null +++ b/results/classifier/118/graphic/441672 @@ -0,0 +1,49 @@ +graphic: 0.885 +device: 0.817 +ppc: 0.803 +x86: 0.792 +architecture: 0.740 +peripherals: 0.691 +performance: 0.682 +network: 0.630 +semantic: 0.630 +socket: 0.618 +debug: 0.617 +vnc: 0.572 +arm: 0.572 +kernel: 0.527 +permissions: 0.525 +user-level: 0.508 +KVM: 0.502 +hypervisor: 0.489 +PID: 0.484 +files: 0.434 +mistranslation: 0.423 +risc-v: 0.390 +boot: 0.386 +register: 0.375 +virtual: 0.341 +VMM: 0.322 +assembly: 0.276 +TCG: 0.246 +i386: 0.228 + +Windos XP BSOD with HP Photosmart usb device attached + +https://bugzilla.redhat.com/show_bug.cgi?id=524723 has all the details of the problem. + +I was just testing attaching a USB device to see if it really worked, and tried my HP Photosmart C5580 All-in-One +printer/scanner, and the Windows XP box then started getting bluescreens and crashing at random +(fairly short :-) intervals. + +My latest attempt was on a fedora rawhide system with pretty up to date software +(qemu-kvm-0.11.0-2.fc12.x86_64), and the crashes still happen. + +A reply to that bugzilla recommended adding this upstream bug, so here it is. + +Please use qemu-1.0 + ehci. The UHCI layer seems to cause this problem when handling some USB 2.0 devices. I had similar problems but with EHCI + qemu-1.0 it was fixed. See docs/usb2.txt for USB 2.0 support. + +Can you still re-create this issue with the latest version of QEMU? If not, I think we should close this bug nowadays... + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/471 b/results/classifier/118/graphic/471 new file mode 100644 index 000000000..0e143821d --- /dev/null +++ b/results/classifier/118/graphic/471 @@ -0,0 +1,94 @@ +graphic: 0.860 +device: 0.847 +performance: 0.832 +semantic: 0.764 +peripherals: 0.655 +permissions: 0.645 +architecture: 0.617 +PID: 0.605 +network: 0.553 +mistranslation: 0.532 +user-level: 0.489 +ppc: 0.462 +socket: 0.450 +boot: 0.443 +debug: 0.439 +arm: 0.421 +files: 0.396 +register: 0.393 +hypervisor: 0.387 +assembly: 0.371 +x86: 0.356 +virtual: 0.342 +vnc: 0.331 +risc-v: 0.295 +i386: 0.268 +TCG: 0.267 +VMM: 0.209 +kernel: 0.161 +KVM: 0.095 + +Clipboard sharing with `qemu_vdagent` does not work with SDL backend +Description of problem: +Clipboard sharing doesn't work: qemu does not send clipboard-grab messages when selecting on the host, nor does it respond to clipboard-grab messages from the guest. +Steps to reproduce: +1. Start QEMU with `qemu_vdagent` and `-display sdl` +2. Try to copy on the host or the guest +3. Observe that the clipboard is not shared +Additional information: +It appears as though `vdagent_clipboard_notify` function is not called. + +Logs: + +With SDL: +``` +vdagent_open +vdagent_recv_chunk size 28 +vdagent_recv_msg msg announce-capabilities, size 8 +vdagent_peer_cap cap mouse-state +vdagent_peer_cap cap monitors-config +vdagent_peer_cap cap reply +vdagent_peer_cap cap clipboard-by-demand +vdagent_peer_cap cap clipboard-selection +vdagent_peer_cap cap sparse-monitors-config +vdagent_peer_cap cap guest-lineend-lf +vdagent_peer_cap cap max-clipboard +vdagent_peer_cap cap audio-volume-sync +vdagent_send msg announce-capabilities +# tried to copy on host -- nothing happens here. +# trying to copy on guest: +vdagent_recv_chunk size 28 +vdagent_recv_msg msg clipboard-grab, size 8 +vdagent_cb_grab_selection selection clipboard +vdagent_cb_grab_type type text +# no response sent +``` +With GTK: +``` +vdagent_open +vdagent_recv_chunk size 28 +vdagent_recv_msg msg announce-capabilities, size 8 +vdagent_peer_cap cap mouse-state +vdagent_peer_cap cap monitors-config +vdagent_peer_cap cap reply +vdagent_peer_cap cap clipboard-by-demand +vdagent_peer_cap cap clipboard-selection +vdagent_peer_cap cap sparse-monitors-config +vdagent_peer_cap cap guest-lineend-lf +vdagent_peer_cap cap max-clipboard +vdagent_peer_cap cap audio-volume-sync +vdagent_send msg announce-capabilities +# trying to copy on host: +vdagent_send msg clipboard-grab +vdagent_recv_chunk size 28 +vdagent_recv_msg msg clipboard-request, size 8 +vdagent_send msg clipboard +vdagent_recv_chunk size 28 +# trying to copy on guest: +vdagent_recv_msg msg clipboard-grab, size 8 +vdagent_cb_grab_selection selection clipboard +vdagent_cb_grab_type type text +vdagent_send msg clipboard-request +vdagent_recv_chunk size 29 +vdagent_recv_msg msg clipboard, size 9 +``` diff --git a/results/classifier/118/graphic/488 b/results/classifier/118/graphic/488 new file mode 100644 index 000000000..6a7025096 --- /dev/null +++ b/results/classifier/118/graphic/488 @@ -0,0 +1,60 @@ +graphic: 0.945 +virtual: 0.888 +device: 0.734 +PID: 0.713 +files: 0.665 +performance: 0.662 +VMM: 0.611 +ppc: 0.592 +semantic: 0.590 +x86: 0.590 +arm: 0.549 +socket: 0.545 +vnc: 0.530 +hypervisor: 0.502 +network: 0.491 +kernel: 0.489 +debug: 0.463 +risc-v: 0.424 +architecture: 0.420 +i386: 0.388 +KVM: 0.371 +peripherals: 0.364 +mistranslation: 0.319 +permissions: 0.315 +TCG: 0.297 +boot: 0.248 +user-level: 0.245 +register: 0.144 +assembly: 0.094 + +[git]Virt-Manager cannot start any previously created virtual machine with Qemu commit bd306cfe: 'spicevmc' is not a valid char driver name +Description of problem: +With qemu built on commit bd306cfe, I'm unable to start a previously created VM. + +Because of both bug #463 and #474 I was blocked from building qemu from git for something like a week or so. My last built and working Qemu is based on commit 9bef7ea9d9. + +Doing a git bissect won't be an easy task :( +Steps to reproduce: +1. Build qemu using commit bd306cfe +2. Launch Virt-Manager +3. Try to launch a previously created VM or try to boot a new one. +Additional information: +Every single time I tried to launch a VM, I get a dialog box with this error message: + +``` +Error starting domain: internal error: qemu unexpectedly closed the monitor: 2021-07-18T07:56:50.116480Z qemu-system-x86_64: -chardev spicevmc,id=charchannel1,name=vdagent: 'spicevmc' is not a valid char driver name + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in startup + self._backend.create() + File "/usr/lib/python3.9/site-packages/libvirt.py", line 1353, in create + raise libvirtError('virDomainCreate() failed') +libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: 2021-07-18T07:56:50.116480Z qemu-system-x86_64: -chardev spicevmc,id=charchannel1,name=vdagent: 'spicevmc' is not a valid char driver name +``` diff --git a/results/classifier/118/graphic/496 b/results/classifier/118/graphic/496 new file mode 100644 index 000000000..5d3c2457f --- /dev/null +++ b/results/classifier/118/graphic/496 @@ -0,0 +1,43 @@ +graphic: 0.978 +architecture: 0.949 +TCG: 0.941 +device: 0.940 +arm: 0.822 +files: 0.793 +boot: 0.733 +ppc: 0.717 +semantic: 0.700 +performance: 0.694 +network: 0.653 +socket: 0.643 +mistranslation: 0.594 +PID: 0.582 +vnc: 0.577 +permissions: 0.565 +register: 0.545 +risc-v: 0.486 +debug: 0.479 +hypervisor: 0.417 +user-level: 0.359 +virtual: 0.297 +peripherals: 0.280 +VMM: 0.273 +x86: 0.241 +assembly: 0.195 +kernel: 0.169 +i386: 0.155 +KVM: 0.021 + +qemu-system-aarch64: ../accel/tcg/cpu-exec.c:681: cpu_loop_exec_tb: Assertion 'icount_enabled()' failed +Description of problem: +When I use qemu-system-aarch64 start a Debian(ARM64) on a mips64el host(ARM64 and X86_64 host don't have this bug), I get a bug as follows: + + +`qemu-system-aarch64: ../accel/tcg/cpu-exec.c:681: cpu_loop_exec_tb: Assertion 'icount_enabled()' failed` + + +The crash code is in ../accel/tcg/cpu-exec.c:681, the code in qemu v5.2.0 as follows: + + +``` +# diff --git a/results/classifier/118/graphic/497 b/results/classifier/118/graphic/497 new file mode 100644 index 000000000..b38ff6fd3 --- /dev/null +++ b/results/classifier/118/graphic/497 @@ -0,0 +1,49 @@ +graphic: 0.924 +device: 0.824 +architecture: 0.821 +vnc: 0.783 +x86: 0.748 +network: 0.675 +virtual: 0.630 +semantic: 0.629 +peripherals: 0.619 +mistranslation: 0.548 +debug: 0.514 +performance: 0.497 +register: 0.392 +hypervisor: 0.349 +permissions: 0.344 +boot: 0.344 +ppc: 0.328 +kernel: 0.324 +PID: 0.317 +risc-v: 0.215 +arm: 0.208 +i386: 0.192 +user-level: 0.189 +TCG: 0.135 +socket: 0.122 +files: 0.081 +assembly: 0.077 +VMM: 0.057 +KVM: 0.053 + +GVT-g + -spice error since qemu 6 +Description of problem: +It doesn't work: +``` +qemu-system-x86_64: The console requires display DMABUF support. +``` + +If I add `gl=on` to `-spice`, it reports: +``` +can't register two opengl displays (spice-egl, egl-headless) +``` +Steps to reproduce: +1. Setup an Intel GVT-g vGPU +2. Run the command +3. See the error +Additional information: +Before 6.0.0 it worked. + +Using VNC instead of SPICE works. diff --git a/results/classifier/118/graphic/504 b/results/classifier/118/graphic/504 new file mode 100644 index 000000000..0de8c4990 --- /dev/null +++ b/results/classifier/118/graphic/504 @@ -0,0 +1,48 @@ +graphic: 0.935 +i386: 0.933 +x86: 0.897 +hypervisor: 0.721 +semantic: 0.696 +performance: 0.666 +KVM: 0.648 +device: 0.546 +virtual: 0.485 +PID: 0.429 +mistranslation: 0.375 +user-level: 0.364 +architecture: 0.360 +debug: 0.283 +peripherals: 0.257 +vnc: 0.227 +VMM: 0.196 +socket: 0.171 +register: 0.168 +files: 0.165 +permissions: 0.154 +boot: 0.135 +risc-v: 0.118 +kernel: 0.118 +network: 0.112 +TCG: 0.083 +ppc: 0.068 +arm: 0.055 +assembly: 0.039 + +kvm_log_clear_one_slot: KVM_CLEAR_DIRTY_LOG failed +Description of problem: +``` + $ ./qemu-system-i386 -enable-kvm -cdrom ubuntu-20.04.2.0-desktop-amd64.iso +qemu-system-i386: kvm_log_clear_one_slot: KVM_CLEAR_DIRTY_LOG failed, slot=9, start=0x0, size=0x10, errno=-14 +qemu-system-i386: kvm_log_clear: kvm log clear failed: mr=vga.vram offset=10000 size=10000 +Aborted + + $ ./qemu-system-x86_64 -enable-kvm -cdrom ubuntu-20.04.2.0-desktop-amd64.iso +qemu-system-x86_64: kvm_log_clear_one_slot: KVM_CLEAR_DIRTY_LOG failed, slot=9, start=0x0, size=0x10, errno=-14 +qemu-system-x86_64: kvm_log_clear: kvm log clear failed: mr=vga.vram offset=0 size=10000 +Aborted +``` +Steps to reproduce: +1. qemu crashes right at start +Additional information: +- last successfully used qemu version: 5.2.0 + - first seen failing qemu version: 6.0 diff --git a/results/classifier/118/graphic/507 b/results/classifier/118/graphic/507 new file mode 100644 index 000000000..9b88e8754 --- /dev/null +++ b/results/classifier/118/graphic/507 @@ -0,0 +1,86 @@ +semantic: 0.943 +graphic: 0.929 +permissions: 0.924 +debug: 0.917 +architecture: 0.913 +register: 0.907 +performance: 0.891 +risc-v: 0.890 +assembly: 0.888 +virtual: 0.888 +device: 0.878 +mistranslation: 0.875 +PID: 0.870 +TCG: 0.864 +kernel: 0.863 +vnc: 0.861 +user-level: 0.855 +arm: 0.854 +socket: 0.846 +boot: 0.842 +VMM: 0.834 +x86: 0.815 +hypervisor: 0.813 +peripherals: 0.811 +ppc: 0.779 +files: 0.774 +KVM: 0.751 +network: 0.749 +i386: 0.617 + +rx / gdbsim-r5f562n7 / serial errors +Description of problem: +Test hangs (about once every two executions) because the console emits an error and expected content is not found. Console content on a failed test execution: + +``` +15:49:05 DEBUG| Linux version 4.19.0+ (yo-satoh@yo-satoh-debian) (gcc version 9.0.0 20181105 (experimental) (GCC)) #137 Wed Feb 20 23:20:02 JST 2019 +15:49:05 DEBUG| Built 1 zonelists, mobility grouping on. Total pages: 8128 +15:49:05 DEBUG| Kernel command line: +15:49:05 DEBUG| Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) +15:49:05 DEBUG| Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) +15:49:05 DEBUG| Memory: 14648K/32768K available (871K kernel code, 95K rwdata, 140K rodata, 96K init, 175K bss, 18120K reserved, 0K cma-reserved) +15:49:05 DEBUG| NR_IRQS: 256 +15:49:05 DEBUG| rx-cmt: used for periodic clock events +15:49:05 DEBUG| clocksource: rx-tpu: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1274173631191 ns +15:49:05 DEBUG| 96.00 BogoMIPS (lpj=480000) +15:49:05 DEBUG| pid_max: default: 4096 minimum: 301 +15:49:05 DEBUG| Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) +15:49:05 DEBUG| Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) +15:49:05 DEBUG| clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +15:49:05 DEBUG| clocksource: Switched to clocksource rx-tpu +15:49:05 DEBUG| workingset: timestamp_bits=30 max_order=12 bucket_order=0 +15:49:05 DEBUG| SuperH (H)SCI(F) driver initialized +15:49:05 DEBUG| 88240.serial: ttySC0 at MMIO 0x88240 (irq = 215, base_baud = 0) is a sci +15:49:05 DEBUG| console [ttySC0] enabled +15:49:05 DEBUG| 88248.serial: ttySC1 at MMIO 0x88248 (irq = 219, base_baud = 0) is a sci +15:49:05 DEBUG| random: get_random_bytes called from 0x01002e48 with crng_init=0 +15:49:05 DEBUG| Freeing unused kernel memory: 96K +15:49:05 DEBUG| This architecture does not have kernel memory protection. +15:49:05 DEBUG| Run /sbin/init as init process +15:49:05 DEBUG| Run /etc/init as init process +15:49:05 DEBUG| Run /bin/init as init process +15:49:05 DEBUG| Run /bin/sh as init process +15:49:05 DEBUG| Sash command shell (version 1.1.1) +15:49:05 DEBUG| />sh-sci 88240.serial: overrun error +15:49:05 DEBUG| sh-sci 88240.serial: frame error +15:49:05 DEBUG| sh-sci 88240.serial: parity error +15:49:09 DEBUG| random: fast init done +``` + +Instead of the last 4 lines seen here, a successful test contains: + +``` +20:59:53 DEBUG| Sash command shell (version 1.1.1) +20:59:53 DEBUG| /> printenv +20:59:53 DEBUG| HOME=/ +20:59:53 DEBUG| TERM=linux +20:59:53 DEBUG| >>> {'execute': 'quit'} +20:59:53 DEBUG| <<< {'return': {}} +``` + +It was also observed that the test is much more prone to fail when it runs restricted to a single CPU (with taskset). It's not clear to me if this is a Kernel or QEMU issue. +Steps to reproduce: +1. ./configure --target-list=rx-softmmu +2. meson compile +3. make check-venv +4. ./tests/venv/bin/avocado run tests/acceptance/machine_rx_gdbsim.py:RxGdbSimMachine.test_linux_sash diff --git a/results/classifier/118/graphic/519 b/results/classifier/118/graphic/519 new file mode 100644 index 000000000..b2865350d --- /dev/null +++ b/results/classifier/118/graphic/519 @@ -0,0 +1,63 @@ +graphic: 0.917 +device: 0.902 +arm: 0.873 +socket: 0.866 +kernel: 0.841 +performance: 0.840 +network: 0.839 +TCG: 0.837 +PID: 0.831 +hypervisor: 0.828 +vnc: 0.820 +risc-v: 0.814 +ppc: 0.808 +peripherals: 0.799 +KVM: 0.775 +VMM: 0.753 +boot: 0.749 +debug: 0.730 +architecture: 0.723 +permissions: 0.722 +register: 0.722 +i386: 0.641 +files: 0.585 +mistranslation: 0.523 +x86: 0.513 +user-level: 0.460 +semantic: 0.425 +assembly: 0.247 +virtual: 0.196 + +xive: An extra '0x' prefix when printing hex values in the trace. +Description of problem: +The trace functions corresponding to the functions below print certain +parameters with a double "0x" prefix, i.e., with "0x0x". + + +- xive_source_esb_read +- xive_source_esb_write +- xive_tctx_tm_write +- xive_tctx_tm_read +Steps to reproduce: +1. Execute the command line on a terminal +2. Watch the terminal for the output. +Additional information: +Sample output: + + xive_end_source_read END 0x0/0xf @0x0x1e0800 + xive_source_esb_read @0x0x210c00 IRQ 0x10 val=0x0x1 + xive_tctx_tm_read @0x0x10038 sz=1 val=0x0 + xive_tctx_tm_write @0x0x10038 sz=1 val=0x80 + xive_tctx_tm_read @0x0x10038 sz=1 val=0x80 + xive_end_source_read END 0x0/0xf @0x0x1e0800 + xive_source_esb_read @0x0x210c00 IRQ 0x10 val=0x0x1 + xive_tctx_tm_read @0x0x10038 sz=1 val=0x0 + xive_tctx_tm_write @0x0x10038 sz=1 val=0x80 + xive_tctx_tm_read @0x0x10038 sz=1 val=0x80 + +The source lines at fault: + + xive_source_esb_read(uint64_t addr, uint32_t srcno, uint64_t value) "@0x0x%"PRIx64" IRQ 0x%x val=0x0x%"PRIx64 + xive_source_esb_write(uint64_t addr, uint32_t srcno, uint64_t value) "@0x0x%"PRIx64" IRQ 0x%x val=0x0x%"PRIx64 + xive_tctx_tm_write(uint64_t offset, unsigned int size, uint64_t value) "@0x0x%"PRIx64" sz=%d val=0x%" PRIx64 + xive_tctx_tm_read(uint64_t offset, unsigned int size, uint64_t value) "@0x0x%"PRIx64" sz=%d val=0x%" PRIx64 diff --git a/results/classifier/118/graphic/526 b/results/classifier/118/graphic/526 new file mode 100644 index 000000000..19a42fd10 --- /dev/null +++ b/results/classifier/118/graphic/526 @@ -0,0 +1,45 @@ +graphic: 0.878 +device: 0.875 +arm: 0.601 +peripherals: 0.600 +mistranslation: 0.554 +performance: 0.549 +socket: 0.517 +ppc: 0.507 +semantic: 0.453 +vnc: 0.425 +register: 0.368 +architecture: 0.362 +risc-v: 0.357 +debug: 0.336 +permissions: 0.317 +boot: 0.282 +virtual: 0.272 +user-level: 0.267 +assembly: 0.260 +TCG: 0.228 +files: 0.171 +PID: 0.160 +network: 0.133 +kernel: 0.129 +hypervisor: 0.086 +VMM: 0.064 +x86: 0.044 +i386: 0.036 +KVM: 0.004 + +MacBook German Keyboard <> and ^° Key not working +Description of problem: +Using a German keyboard on my 2018 MacBook Pro I can't type the <> Key or the ^ Key. +When pressing the <> Key it gets interpreted as the ^ Key, the ^ Key is dead. + +Problem is not caused by the guest system, Ubuntu VMs also can't type <>. (Ubuntu VMs ran inside UTM, which internally uses QEMU. https://mac.getutm.app/ ) + +VirtualBox maps the <> Key and ^ Key correctly. +Steps to reproduce: +0. Use a MacBook with a German Keyboard +1. Install TempleOS +2. Install German Keyboard Layout from https://github.com/Rion96/GKey (mount the ISO as a CD Drive) +3. Every key works except for <> and ^. +Additional information: +Doing the same steps in VirtualBox results in <> and ^ working, so it must be a QEMU error. diff --git a/results/classifier/118/graphic/546458 b/results/classifier/118/graphic/546458 new file mode 100644 index 000000000..bbf8f8c55 --- /dev/null +++ b/results/classifier/118/graphic/546458 @@ -0,0 +1,362 @@ +graphic: 0.860 +semantic: 0.855 +performance: 0.850 +debug: 0.836 +KVM: 0.827 +mistranslation: 0.822 +permissions: 0.820 +register: 0.818 +assembly: 0.812 +TCG: 0.799 +kernel: 0.794 +VMM: 0.769 +user-level: 0.768 +virtual: 0.767 +PID: 0.759 +arm: 0.752 +network: 0.733 +device: 0.728 +architecture: 0.726 +vnc: 0.717 +ppc: 0.714 +hypervisor: 0.712 +socket: 0.699 +peripherals: 0.666 +risc-v: 0.652 +files: 0.630 +boot: 0.608 +x86: 0.566 +i386: 0.280 + +kernel NULL pointer in -virtual (-server) kernel + +When stress testing eucalyptus we have run into this oops inside VMs +[ 82.907577] BUG: unable to handle kernel NULL pointer dereference at 0000000000000358^M +[ 82.908842] IP: [<ffffffff813982e8>] sym_int_sir+0x2a8/0x750^M +[ 82.909773] PGD 0 ^M +[ 82.910110] Thread overran stack, or stack corrupted^M +[ 82.910870] Oops: 0000 [#1] SMP ^M +[ 82.911407] last sysfs file: /sys/devices/virtual/block/ram9/uevent^M + +We launched 18 instances, 2 of them failed this way. The instances run with 192M of memory. With 6 VM launches on a single node all at the same time the host is under heavy load. + +This occurred in 20100323 lucid x86_64 uec-image instance. + +ProblemType: Bug +AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access /dev/snd/: No such file or directory +AplayDevices: Error: [Errno 2] No such file or directory +Architecture: amd64 +ArecordDevices: Error: [Errno 2] No such file or directory +CurrentDmesg: + +Date: Wed Mar 24 22:06:32 2010 +DistroRelease: Ubuntu 10.04 +Frequency: Once a day. +Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub +MachineType: Bochs Bochs +Package: linux-image-2.6.32-16-virtual 2.6.32-16.25 +PciMultimedia: + +ProcCmdLine: root=/dev/sda1 console=ttyS0 +ProcEnviron: + LANG=en_US.UTF-8 + SHELL=/bin/bash +ProcVersionSignature: User Name 2.6.32-16.25-server +Regression: No +Reproducible: No +SourcePackage: linux +TestedUpstream: No +Uname: Linux 2.6.32-16-server x86_64 +dmi.bios.date: 01/01/2007 +dmi.bios.vendor: Bochs +dmi.bios.version: Bochs +dmi.chassis.type: 1 +dmi.chassis.vendor: Bochs +dmi.modalias: dmi:bvnBochs:bvrBochs:bd01/01/2007:svnBochs:pnBochs:pvr:cvnBochs:ct1:cvr: +dmi.product.name: Bochs +dmi.sys.vendor: Bochs + + + +I saw this https://bugzilla.redhat.com/show_bug.cgi?id=560114 which links to http://<email address hidden>/msg08927.html + + +just for the record, ubuntu-bug was run on a different instance (same kernel/filesystem, but not the one that failed) + +Hi Scott, + +This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ . + +If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report. + +apport-collect -p linux 546458 + +Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results. + +Thanks in advance. + + [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.] + + +This is still a concern, and not easily reproducible. I would rather keep it open, unless you have reason to consider the OOPS resolved on current 2.6.32-21. I am stress-testing (by extension) kvm, and hopefully either I can state it has not happened on the last (few) thousands tries, and recornfirm it. + +then let's set the linux task to Triaged. i only like to use 'new' for actual new bugs. :-) + +~JFo + +I see no indication that this is actually a qemu issue. If there's any evidence that it is, please reopen. + +Just to confirm -- still present, 10.04 LTS up-to-date, UEC images also 10.04 up-to-date. A 2,000 run creating KVM instances under Eucalyptus shows 6 occurences of this OOPS: + +WARNING:INSTANCE i-3EDE078A:[ 129.998256] BUG: unable to handle kernel NULL pointer dereference at 00000358 +WARNING:INSTANCE i-406C06CE:[ 89.245841] BUG: unable to handle kernel NULL pointer dereference at 0000000000000358 +WARNING:INSTANCE i-411D0851:[ 158.375444] BUG: unable to handle kernel NULL pointer dereference at 00000358 +WARNING:INSTANCE i-4E1C08D4:[ 196.089623] BUG: unable to handle kernel NULL pointer dereference at 0000000000000358 +WARNING:INSTANCE i-54800A8D:[ 67.825483] BUG: unable to handle kernel NULL pointer dereference at 0000000000000358 +WARNING:INSTANCE i-5E970AA3:[ 87.610866] BUG: unable to handle kernel NULL pointer dereference at 00000358 + + +Per comment #7, marking this invalid for qemu-kvm. + +Description of problem: + +During an VNC installation on a virt guest, the installer appeared to hang while installing the bootloader. Closer inspection on the console shows a kernel NULL pointer dereference. + +Version-Release number of selected component (if applicable): + + * anaconda-13.23 + * kernel-2.6.33-0.23.rc5.git1.fc13.x86_64 + +How reproducible: + * This is the first time out of 8 or more installs + +Steps to Reproduce: +1. Perform an installation against http://alt.fedoraproject.org/pub/alt/stage/rawhide-testing/ + +Actual results: + +Running anaconda 13.23, the Fedora system installer - please wait. +21:09:16 Starting VNC... +21:09:17 The VNC server is now running. +21:09:17 + +WARNING!!! VNC server running with NO PASSWORD! +You can use the vncpassword=<password> boot option +if you would like to secure the server. + + +21:09:17 Please manually connect your vnc client to test1200.test.redhat.com:1 (10.10.10.200) to begin the install. +Press <enter> for a shell +21:09:18 Starting graphical installation. + +sh-4.1# BUG: unable to handle kernel NULL pointer dereference at 0000000000000358 +IP: [<ffffffffa010846b>] sym_int_sir+0x646/0x1549 [sym53c8xx] +PGD 2b2ef067 PUD 3eea2067 PMD 0 +Oops: 0000 [#1] SMP +last sysfs file: /sys/devices/pci0000:00/0000:00:04.0/host2/target2:0:0/2:0:0:0/block/sda/removable +CPU 0 +Pid: 0, comm: swapper Not tainted 2.6.33-0.23.rc5.git1.fc13.x86_64 #1 / +RIP: 0010:[<ffffffffa010846b>] [<ffffffffa010846b>] sym_int_sir+0x646/0x1549 [sym53c8xx] +RSP: 0018:ffff880003c039b0 EFLAGS: 00010087 +RAX: 000000000000000a RBX: ffff88003e41c000 RCX: 0000000000000070 +RDX: 0000000000000000 RSI: ffffffffa0103c22 RDI: ffffc90000a5a006 +RBP: ffff880003c03a30 R08: ffffffff81a4b830 R09: 0000000000000001 +R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 +R13: ffff88003e41c090 R14: ffff88003e6a800b R15: 0000000000000084 +FS: 0000000000000000(0000) GS:ffff880003c00000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b +CR2: 0000000000000358 CR3: 000000002b2ec000 CR4: 00000000000006f0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +Process swapper (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a4b020) +Stack: + 0000000000000000 0000000000000002 ffffffff81a4b020 0000000000000000 +<0> 0000000000000000 0000000000000000 0000000000000000 0000000000000046 +<0> 0000000000000000 0000000000000000 ffff880003c03a60 ffff88003e41c000 +Call Trace: + <IRQ> + [<ffffffffa010980c>] sym_interrupt+0x49e/0x6d2 [sym53c8xx] + [<ffffffffa0103c2a>] sym53c8xx_intr+0x4d/0x7b [sym53c8xx] + [<ffffffff810abec8>] handle_IRQ_event+0x53/0x119 + [<ffffffff810add95>] handle_fasteoi_irq+0x90/0xd0 + [<ffffffff8100c437>] handle_irq+0x88/0x91 + [<ffffffff8147ca74>] do_IRQ+0x5c/0xc3 + [<ffffffff81477b13>] ret_from_intr+0x0/0x16 + [<ffffffff814778d6>] ? _raw_spin_unlock_irqrestore+0x4c/0x56 + [<ffffffff812fb08f>] ? spin_unlock_irqrestore+0xe/0x10 + [<ffffffff812fbb16>] ? scsi_dispatch_cmd+0x1c1/0x234 + [<ffffffff81301b81>] ? scsi_request_fn+0x476/0x4a3 + [<ffffffff812152ed>] ? __blk_run_queue+0x45/0x74 + [<ffffffff812153d1>] ? blk_run_queue+0x26/0x3a + [<ffffffff81300ff4>] ? scsi_run_queue+0x300/0x3ac + [<ffffffff812e8964>] ? put_device+0x17/0x19 + [<ffffffff81301ddc>] ? scsi_next_command+0x3b/0x4b + [<ffffffff813027cb>] ? scsi_io_completion+0x1f7/0x448 + [<ffffffff81300c43>] ? spin_unlock_irqrestore+0xe/0x10 + [<ffffffff812fb834>] ? scsi_finish_command+0xf5/0xfe + [<ffffffff81302b42>] ? scsi_softirq_done+0x111/0x11a + [<ffffffff8121a69a>] ? blk_done_softirq+0x82/0x92 + [<ffffffff810567e4>] ? __do_softirq+0xf8/0x1cd + [<ffffffff8100ab9c>] ? call_softirq+0x1c/0x30 + [<ffffffff8100c357>] ? do_softirq+0x4b/0xa3 + [<ffffffff810563cf>] ? irq_exit+0x4a/0x8c + [<ffffffff8147cac4>] ? do_IRQ+0xac/0xc3 + [<ffffffff81477b13>] ? ret_from_intr+0x0/0x16 + <EOI> + [<ffffffff81029289>] ? native_safe_halt+0xb/0xd + [<ffffffff8107d04f>] ? trace_hardirqs_on+0xd/0xf + [<ffffffff810115f5>] ? default_idle+0x3b/0x5d + [<ffffffff81008bfc>] ? cpu_idle+0xaf/0xe9 + [<ffffffff8145ed6a>] ? rest_init+0x7e/0x80 + [<ffffffff81d82e2f>] ? start_kernel+0x440/0x44b + [<ffffffff81d822bc>] ? x86_64_start_reservations+0xa7/0xab + [<ffffffff81d823b8>] ? x86_64_start_kernel+0xf8/0x107 +Code: b2 d5 10 a0 48 89 da eb 65 48 8b 9f b0 01 00 00 48 81 c7 a0 01 00 00 e8 68 02 1e e1 48 c7 c7 ec d5 10 a0 48 89 c6 48 89 da eb 6f <49> 8b 84 24 58 03 00 00 48 8b 90 80 00 00 00 48 8b 38 4c 8b a2 +RIP [<ffffffffa010846b>] sym_int_sir+0x646/0x1549 [sym53c8xx] + RSP <ffff880003c039b0> +CR2: 0000000000000358 +---[ end trace f535af648735afc9 ]--- +Kernel panic - not syncing: Fatal exception in interrupt +Pid: 0, comm: swapper Tainted: G D 2.6.33-0.23.rc5.git1.fc13.x86_64 #1 +Call Trace: + <IRQ> [<ffffffff81474628>] panic+0x7a/0x142 + [<ffffffff81478b03>] oops_end+0xb7/0xc7 + [<ffffffff8102f869>] no_context+0x1fc/0x20b + [<ffffffff81029d1a>] ? pvclock_clocksource_read+0x47/0x83 + [<ffffffff8102fa0a>] __bad_area_nosemaphore+0x192/0x1b5 + [<ffffffff81029237>] ? kvm_clock_read+0x21/0x23 + [<ffffffff8102fa40>] bad_area_nosemaphore+0x13/0x15 + [<ffffffff8147a60b>] do_page_fault+0x16f/0x2df + [<ffffffff81477e75>] page_fault+0x25/0x30 + [<ffffffffa0103c22>] ? sym53c8xx_intr+0x45/0x7b [sym53c8xx] + [<ffffffffa010846b>] ? sym_int_sir+0x646/0x1549 [sym53c8xx] + [<ffffffffa010980c>] sym_interrupt+0x49e/0x6d2 [sym53c8xx] + [<ffffffffa0103c2a>] sym53c8xx_intr+0x4d/0x7b [sym53c8xx] + [<ffffffff810abec8>] handle_IRQ_event+0x53/0x119 + [<ffffffff810add95>] handle_fasteoi_irq+0x90/0xd0 + [<ffffffff8100c437>] handle_irq+0x88/0x91 + [<ffffffff8147ca74>] do_IRQ+0x5c/0xc3 + [<ffffffff81477b13>] ret_from_intr+0x0/0x16 + [<ffffffff814778d6>] ? _raw_spin_unlock_irqrestore+0x4c/0x56 + [<ffffffff812fb08f>] ? spin_unlock_irqrestore+0xe/0x10 + [<ffffffff812fbb16>] ? scsi_dispatch_cmd+0x1c1/0x234 + [<ffffffff81301b81>] ? scsi_request_fn+0x476/0x4a3 + [<ffffffff812152ed>] ? __blk_run_queue+0x45/0x74 + [<ffffffff812153d1>] ? blk_run_queue+0x26/0x3a + [<ffffffff81300ff4>] ? scsi_run_queue+0x300/0x3ac + [<ffffffff812e8964>] ? put_device+0x17/0x19 + [<ffffffff81301ddc>] ? scsi_next_command+0x3b/0x4b + [<ffffffff813027cb>] ? scsi_io_completion+0x1f7/0x448 + [<ffffffff81300c43>] ? spin_unlock_irqrestore+0xe/0x10 + [<ffffffff812fb834>] ? scsi_finish_command+0xf5/0xfe + [<ffffffff81302b42>] ? scsi_softirq_done+0x111/0x11a + [<ffffffff8121a69a>] ? blk_done_softirq+0x82/0x92 + [<ffffffff810567e4>] ? __do_softirq+0xf8/0x1cd + [<ffffffff8100ab9c>] ? call_softirq+0x1c/0x30 + [<ffffffff8100c357>] ? do_softirq+0x4b/0xa3 + [<ffffffff810563cf>] ? irq_exit+0x4a/0x8c + [<ffffffff8147cac4>] ? do_IRQ+0xac/0xc3 + [<ffffffff81477b13>] ? ret_from_intr+0x0/0x16 + <EOI> [<ffffffff81029289>] ? native_safe_halt+0xb/0xd + [<ffffffff8107d04f>] ? trace_hardirqs_on+0xd/0xf + [<ffffffff810115f5>] ? default_idle+0x3b/0x5d + [<ffffffff81008bfc>] ? cpu_idle+0xaf/0xe9 + [<ffffffff8145ed6a>] ? rest_init+0x7e/0x80 + [<ffffffff81d82e2f>] ? start_kernel+0x440/0x44b + [<ffffffff81d822bc>] ? x86_64_start_reservations+0xa7/0xab + [<ffffffff81d823b8>] ? x86_64_start_kernel+0xf8/0x107 + + +Expected results: + +No kernel oops + +This seems to be the same kvm scsi emulation issue reported and discussed on the LKML, + http://<email address hidden>/msg08927.html + +and also Debian bug #511914 + http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511914 + +Rgds, Ariel + +Which qemu-kvm version are you using? Could you try the one from virt-preview? + +qemu's SCSI support isn't the one that gets most developer attention; can you please try ide or virtio? + +(In reply to comment #2) +> Which qemu-kvm version are you using? Could you try the one from virt-preview? + + * qemu-kvm-0.11.0-12.fc12.x86_64 + +I'm running into other issues when trying to use the F-12 virt-preview repository. I'll take those to <email address hidden> for feedback. + +> qemu's SCSI support isn't the one that gets most developer attention; can you +> please try ide or virtio? + +I can work around this by using ide or virtio. This is certainly specific to SCSI KVM installs. + +(In reply to comment #3) +> (In reply to comment #2) +> > Which qemu-kvm version are you using? Could you try the one from virt-preview? +> +> * qemu-kvm-0.11.0-12.fc12.x86_64 +> +> I'm running into other issues when trying to use the F-12 virt-preview +> repository. I'll take those to <email address hidden> for feedback. + +I'm still not able to start a guest using virt-preview repository. I've filed bug#566425 to address that issue. + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + +This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. + + +This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. +Changing version to '13'. + +More information and reason for this action is here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + +The issue which blocks use of virt-preview/F-13 qemu has been resolved. Would it be possible to retest with qemu-0.12.x on the host? + + +This message is a reminder that Fedora 13 is nearing its end of life. +Approximately 30 (thirty) days from now Fedora will stop maintaining +and issuing updates for Fedora 13. It is Fedora's policy to close all +bug reports from releases that are no longer maintained. At that time +this bug will be closed as WONTFIX if it remains open with a Fedora +'version' of '13'. + +Package Maintainer: If you wish for this bug to remain open because you +plan to fix it in a currently maintained version, simply change the 'version' +to a later Fedora version prior to Fedora 13's end of life. + +Bug Reporter: Thank you for reporting this issue and we are sorry that +we may not be able to fix it before Fedora 13 is end of life. If you +would still like to see this bug fixed and are able to reproduce it +against a later version of Fedora please change the 'version' of this +bug to the applicable version. If you are unable to change the version, +please add a comment here and someone will do it for you. + +Although we aim to fix as many bugs as possible during every release's +lifetime, sometimes those efforts are overtaken by events. Often a +more recent Fedora release includes newer upstream software that fixes +bugs or makes them obsolete. + +The process we are following is described here: +http://fedoraproject.org/wiki/BugZappers/HouseKeeping + + +Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is +no longer maintained, which means that it will not receive any further +security or bug fix updates. As a result we are closing this bug. + +If you can reproduce this bug against a currently maintained version of +Fedora please feel free to reopen this bug against that version. + +Thank you for reporting this bug and we are sorry it could not be fixed. + +Closing this bug with Won't fix as this kernel / release is no longer supported. +Please feel free to open a new bug report if you're still experiencing this on a newer release (Bionic 18.04.3 / Disco 19.04) +Thanks! + diff --git a/results/classifier/118/graphic/553 b/results/classifier/118/graphic/553 new file mode 100644 index 000000000..2cad918e3 --- /dev/null +++ b/results/classifier/118/graphic/553 @@ -0,0 +1,55 @@ +graphic: 0.992 +x86: 0.984 +debug: 0.972 +device: 0.966 +PID: 0.900 +peripherals: 0.882 +mistranslation: 0.858 +i386: 0.814 +performance: 0.812 +ppc: 0.802 +hypervisor: 0.780 +semantic: 0.751 +network: 0.740 +virtual: 0.733 +vnc: 0.727 +architecture: 0.725 +boot: 0.725 +VMM: 0.708 +socket: 0.666 +risc-v: 0.635 +files: 0.605 +TCG: 0.574 +kernel: 0.565 +register: 0.535 +arm: 0.524 +KVM: 0.475 +permissions: 0.435 +user-level: 0.425 +assembly: 0.339 + +Virtio-vga with blobs on fails, when qemu compiled with enabled modules +Description of problem: +When using qemu configured with `--enabled-modules` and starting qemu with command line above, qemu crashes with following output: +``` +qemu-system-x86_64: -device virtio-vga,blob=on: cannot enable blob resources without udmabuf +``` +While qemu configured without `--enabled-modules` runs this command successfully. +Steps to reproduce: +1. Get latest qemu source code +2. Build qemu `mkdir build && cd build && ../configure && ninja` +3. Check if following command runs without errors and show sdl qemu window + ``` + sudo ./qemu-system-x86_64 \ + -object memory-backend-memfd,id=mem1,size=512M \ + -machine memory-backend=mem1 \ + -display sdl \ + -device virtio-vga,blob=on + + ``` +4. Then try to build with modules enabled `mkdir build && cd build && ../configure --enable-modules && ninja` +5. Try to do step 3 again +Additional information: +I tried to debug this bug, and found that problem is with function `virtio_gpu_have_udmabuf`: when qemu is build without modules this function is from `hw/display/virtio-gpu-udmabuf.c` (which is correct), but when qemu compiled with modules this function comes from `stubs/virtio-gpu-udmabuf.c` and when `hw-display-virtio-gpu.so` is loaded, `virtio_gpu_have_udmabuf` is not replaced, and remains function from stub (which always return 0) and command fails. + +I think I will submit patch that fix it tomorrow diff --git a/results/classifier/118/graphic/55961334 b/results/classifier/118/graphic/55961334 new file mode 100644 index 000000000..ccb15ecf3 --- /dev/null +++ b/results/classifier/118/graphic/55961334 @@ -0,0 +1,64 @@ +graphic: 0.909 +KVM: 0.881 +x86: 0.812 +architecture: 0.788 +hypervisor: 0.788 +semantic: 0.775 +files: 0.766 +device: 0.764 +performance: 0.758 +mistranslation: 0.718 +ppc: 0.710 +vnc: 0.709 +network: 0.697 +kernel: 0.693 +PID: 0.683 +user-level: 0.681 +socket: 0.636 +debug: 0.604 +arm: 0.601 +boot: 0.569 +permissions: 0.560 +virtual: 0.540 +risc-v: 0.488 +register: 0.485 +peripherals: 0.484 +VMM: 0.474 +i386: 0.462 +TCG: 0.429 +assembly: 0.395 + +[Bug] "-ht" flag ignored under KVM - guest still reports HT + +Hi Community, +We have observed that the 'ht' feature bit cannot be disabled when QEMU runs +with KVM acceleration. +qemu-system-x86_64 \ + --enable-kvm \ + -machine q35 \ + -cpu host,-ht \ + -smp 4 \ + -m 4G \ + -drive file=rootfs.img,format=raw \ + -nographic \ + -append 'console=ttyS0 root=/dev/sda rw' +Because '-ht' is specified, the guest should expose no HT capability +(cpuid.1.edx[28] = 0), and /proc/cpuinfo shouldn't show HT feature, but we still +saw ht in linux guest when run 'cat /proc/cpuinfo'. +XiaoYao mentioned that: + +It has been the behavior of QEMU since + + commit 400281af34e5ee6aa9f5496b53d8f82c6fef9319 + Author: Andre Przywara <andre.przywara@amd.com> + Date: Wed Aug 19 15:42:42 2009 +0200 + + set CPUID bits to present cores and threads topology + +that we cannot remove HT CPUID bit from guest via "-cpu xxx,-ht" if the +VM has >= 2 vcpus. +I'd like to know whether there's a plan to address this issue, or if the current +behaviour is considered acceptable. +Best regards, +Ewan. + diff --git a/results/classifier/118/graphic/567376 b/results/classifier/118/graphic/567376 new file mode 100644 index 000000000..d52f24a56 --- /dev/null +++ b/results/classifier/118/graphic/567376 @@ -0,0 +1,41 @@ +graphic: 0.926 +mistranslation: 0.920 +device: 0.818 +architecture: 0.770 +debug: 0.703 +performance: 0.660 +semantic: 0.635 +PID: 0.601 +network: 0.570 +vnc: 0.522 +permissions: 0.511 +files: 0.474 +socket: 0.460 +arm: 0.439 +VMM: 0.427 +risc-v: 0.415 +hypervisor: 0.411 +user-level: 0.407 +boot: 0.386 +kernel: 0.364 +register: 0.341 +ppc: 0.299 +TCG: 0.281 +peripherals: 0.224 +virtual: 0.136 +i386: 0.081 +x86: 0.068 +assembly: 0.066 +KVM: 0.025 + +qemu-img fails to convert image + +On a Windows XP system and an NTFS drive, using QEMU on Windows Ver 0.12.2 from http://homepage3.nifty.com/takeda-toshiya/qemu/ or QEMU 0.12.3 built locally, when I run the following commands, a dialog is displayed indicating that "qemu-img.exe has encountered a problem and needs to close". + + qemu-img create foo.img 1G + qemu-img convert -O qcow2 foo.img bar.img + +0.15.0 under win7 64-bit seems to work OK. + +Looking at comment #1, it sounds like this has been fixed, so let's close this ticket now. + diff --git a/results/classifier/118/graphic/567380 b/results/classifier/118/graphic/567380 new file mode 100644 index 000000000..7075adf25 --- /dev/null +++ b/results/classifier/118/graphic/567380 @@ -0,0 +1,52 @@ +graphic: 0.922 +mistranslation: 0.913 +semantic: 0.858 +device: 0.807 +performance: 0.783 +files: 0.761 +architecture: 0.738 +network: 0.699 +PID: 0.665 +user-level: 0.658 +socket: 0.652 +kernel: 0.623 +hypervisor: 0.618 +ppc: 0.583 +register: 0.567 +permissions: 0.566 +boot: 0.545 +debug: 0.528 +risc-v: 0.508 +virtual: 0.492 +vnc: 0.491 +VMM: 0.490 +TCG: 0.468 +assembly: 0.468 +x86: 0.412 +peripherals: 0.399 +arm: 0.395 +i386: 0.277 +KVM: 0.269 + +qemu-img fails to create images >= 4G + +On a Windows XP system and an NTFS drive, using QEMU on Windows Ver 0.12.2 from http://homepage3.nifty.com/takeda-toshiya/qemu/ or QEMU 0.12.3 or d3538b45ea88e82d1b01959b4ca55d3696b71cb2 built locally, when I run the following command, a zero-length file is created. + + qemu-img create foo.img 4G + +Confirmed under Win 7 64-bit. +Also does same thing on v10.6, v11.1, v12.1 + +what a zero-length file means? Run the following command to see +qemu-img info foo.img + +The file size was zero bytes (i.e., it contained no data). + +I've tried again with QEMU 2.6.50 on a Windows 7 Professional system and it appears to have created the s + +Sorry, I accidentally submitted comment #3 without finishing it. + +I was going to say that when I tried QEMU 2.6.50 on a Windows 7 Professional system, it appears to have created the image file successfully. + +Thanks for the update ... since it is working with the current version of QEMU, I assume this problem has been fixed sometimes during the past years, thus we can close this ticket now. + diff --git a/results/classifier/118/graphic/577 b/results/classifier/118/graphic/577 new file mode 100644 index 000000000..012c060de --- /dev/null +++ b/results/classifier/118/graphic/577 @@ -0,0 +1,55 @@ +graphic: 0.942 +files: 0.938 +mistranslation: 0.885 +performance: 0.884 +device: 0.793 +user-level: 0.759 +semantic: 0.732 +architecture: 0.701 +PID: 0.643 +network: 0.590 +vnc: 0.571 +debug: 0.517 +permissions: 0.493 +TCG: 0.483 +VMM: 0.451 +socket: 0.435 +boot: 0.403 +kernel: 0.379 +ppc: 0.368 +risc-v: 0.320 +x86: 0.318 +arm: 0.316 +hypervisor: 0.246 +i386: 0.238 +virtual: 0.234 +register: 0.197 +peripherals: 0.193 +assembly: 0.084 +KVM: 0.075 + +getdtablesize() returns wrong value in qemu user mode on Linux/alpha +Description of problem: +The `getdtablesize()` function returns a value that is too large. Namely, `getdtablesize() - 1` ought to be a valid file descriptor, but is not. +Steps to reproduce: +[foo.c](/uploads/7a9e99d3811fe4a7eef183ed98c966a4/foo.c) + +1. +``` +# apt install g++-10-alpha-linux-gnu +``` +2. +``` +$ alpha-linux-gnu-gcc-10 -Wall -static foo.c +``` +[a.out](/uploads/4fffa6dd2332885f51e4030dcbe25644/a.out) + +3. Transfer the a.out file to a Linux/alpha machine; execute it there. The return code is 0. +4. +``` +$ QEMU_LD_PREFIX=/usr/alpha-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-alpha ./a.out ; echo $? +``` +Expected: `0` +Actual: `1` +Additional information: + diff --git a/results/classifier/118/graphic/578 b/results/classifier/118/graphic/578 new file mode 100644 index 000000000..4f2fd398b --- /dev/null +++ b/results/classifier/118/graphic/578 @@ -0,0 +1,60 @@ +graphic: 0.967 +performance: 0.896 +user-level: 0.873 +device: 0.844 +network: 0.826 +files: 0.813 +PID: 0.794 +semantic: 0.794 +architecture: 0.773 +hypervisor: 0.771 +TCG: 0.769 +mistranslation: 0.765 +kernel: 0.758 +vnc: 0.745 +VMM: 0.720 +permissions: 0.708 +socket: 0.700 +boot: 0.689 +ppc: 0.655 +debug: 0.653 +risc-v: 0.605 +arm: 0.552 +KVM: 0.430 +peripherals: 0.425 +register: 0.423 +virtual: 0.421 +x86: 0.293 +assembly: 0.277 +i386: 0.186 + +getdomainname() is not implemented in QEMU user mode on Linux/sparc64 +Description of problem: +The `getdomainname()` function fails, instead of succeeding. +Steps to reproduce: +[foo.c](/uploads/7586c9aab788855b232a5c2f6aaeb4fc/foo.c) + +1. +``` +# apt install g++-10-sparc64-linux-gnu +# mkdir -p /usr/sparc64-linux-gnu/etc +# touch /usr/sparc64-linux-gnu/etc/ld.so.cache +``` +2. +``` +$ sparc64-linux-gnu-gcc-10 -Wall -static foo.c +``` +[a.out](/uploads/39d291b95caa182d74b0b622a82667e8/a.out) + +3. Transfer the a.out file to a Linux/sparc64 machine; execute it there. It prints +``` +result: (none) +``` +4. +``` +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-sparc64 ./a.out +``` +Expected: `result: (none)` +Actual: `getdomainname: Function not implemented` +Additional information: + diff --git a/results/classifier/118/graphic/579 b/results/classifier/118/graphic/579 new file mode 100644 index 000000000..407aa520d --- /dev/null +++ b/results/classifier/118/graphic/579 @@ -0,0 +1,80 @@ +graphic: 0.973 +user-level: 0.953 +performance: 0.950 +mistranslation: 0.937 +semantic: 0.929 +architecture: 0.922 +files: 0.916 +device: 0.911 +permissions: 0.888 +debug: 0.871 +kernel: 0.823 +hypervisor: 0.803 +PID: 0.796 +socket: 0.791 +network: 0.782 +ppc: 0.745 +TCG: 0.688 +VMM: 0.664 +peripherals: 0.657 +vnc: 0.652 +risc-v: 0.606 +boot: 0.603 +arm: 0.598 +register: 0.585 +assembly: 0.523 +KVM: 0.518 +x86: 0.514 +virtual: 0.430 +i386: 0.272 + +chown() fails when it should succeed in QEMU user mode on Linux/sparc64 +Description of problem: +The `chown()` function fails, instead of succeeding, in a particular situation. +Steps to reproduce: +[foo.c](/uploads/630d9b83671a071f4ded4da43b6c1b9b/foo.c) + +1. +``` +# apt install g++-10-sparc64-linux-gnu +# mkdir -p /usr/sparc64-linux-gnu/etc +# touch /usr/sparc64-linux-gnu/etc/ld.so.cache +``` +2. +``` +$ sparc64-linux-gnu-gcc-10 -Wall -static foo.c +``` +[a.out](/uploads/bbab43a1b78e6d16ee13e0eff5e963a5/a.out) + +3. Transfer the a.out file to a Linux/sparc64 machine; execute these commands there: +``` +$ id +``` +Verify that you are in 2 or more groups. +``` +$ touch file +$ ln -s file link +$ ln -s link link2 +$ ./a.out; echo $? +``` +It prints `0`. + +4. +``` +$ id +``` +Verify that you are in 2 or more groups. +``` +$ touch file +$ ln -s file link +$ ln -s link link2 +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-sparc64 ./a.out; echo $? +``` +Expected: `0` +Actual: +``` +chown: Operation not permitted +1 +``` +Additional information: + diff --git a/results/classifier/118/graphic/581353 b/results/classifier/118/graphic/581353 new file mode 100644 index 000000000..c23876874 --- /dev/null +++ b/results/classifier/118/graphic/581353 @@ -0,0 +1,46 @@ +graphic: 0.811 +device: 0.784 +debug: 0.783 +semantic: 0.718 +boot: 0.683 +mistranslation: 0.619 +kernel: 0.601 +socket: 0.598 +user-level: 0.554 +performance: 0.549 +network: 0.497 +risc-v: 0.481 +x86: 0.464 +architecture: 0.458 +PID: 0.454 +i386: 0.430 +vnc: 0.421 +register: 0.411 +permissions: 0.404 +ppc: 0.396 +VMM: 0.361 +arm: 0.355 +KVM: 0.339 +files: 0.319 +hypervisor: 0.280 +virtual: 0.274 +peripherals: 0.230 +TCG: 0.230 +assembly: 0.182 + +qemu doesn't stop execution upon hitting a breakpoint + +Using Qemu 0.12.3 and gdb 7.1 on Ubuntu Lucid. + +I'm trying to debug some bootloader code. Using qemu -s -S to run the bootloader and gdb to connect to qemu, I set the breakpoint at 0x7c00. Then I type continue in gdb. The breakpoint is hit and gdb shows debug information. However qemu apparently continues to execute the code of the bootloader as the text is printed on the screen etc. + +Attached is the bootloader (no debug symbols as I'm debugging without them) + +Same thing happens to me, same versions as above.. I must turn to another app to accomplish my work while awaiting for a bug-fix, the code is perfectly executed but while gdb hits the breakpoints qemu goes on.. + +Ok this issue has been fixed in qemu 0.12.4. + +Just type 'qemu --version' to see what version you have, it is probably outdated. + +According to comment #3, this has been fixed, so let's change the bug status accordingly. + diff --git a/results/classifier/118/graphic/588688 b/results/classifier/118/graphic/588688 new file mode 100644 index 000000000..6b70cee5e --- /dev/null +++ b/results/classifier/118/graphic/588688 @@ -0,0 +1,42 @@ +graphic: 0.843 +device: 0.833 +performance: 0.720 +architecture: 0.667 +mistranslation: 0.657 +semantic: 0.635 +socket: 0.612 +register: 0.610 +kernel: 0.598 +PID: 0.570 +permissions: 0.561 +user-level: 0.538 +risc-v: 0.528 +network: 0.515 +files: 0.481 +boot: 0.473 +ppc: 0.471 +vnc: 0.467 +i386: 0.456 +peripherals: 0.445 +KVM: 0.437 +TCG: 0.435 +VMM: 0.414 +assembly: 0.385 +x86: 0.384 +debug: 0.369 +hypervisor: 0.356 +arm: 0.320 +virtual: 0.190 + +Hard disk images are supporting ATAPI commands. They should fail. + +When using a hard disk image (qcow, qcow2, vdi, vmdk, bochs), the emulated device can be a CD-ROM and support ATAPI commands. + +These commands fails in real hard disks and these images are not prepared to handle optical disk formats, they should fail also. + +Only images able to handle that formats (dmg, raw, host) should work with ATAPI commands and CD-ROM devices. + +Looking through old bug tickets ... is this still an issue with the latest version of QEMU, or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/589315 b/results/classifier/118/graphic/589315 new file mode 100644 index 000000000..1d81ae881 --- /dev/null +++ b/results/classifier/118/graphic/589315 @@ -0,0 +1,66 @@ +graphic: 0.939 +socket: 0.939 +x86: 0.868 +semantic: 0.837 +device: 0.836 +network: 0.793 +peripherals: 0.697 +ppc: 0.676 +performance: 0.562 +architecture: 0.555 +PID: 0.531 +user-level: 0.496 +kernel: 0.479 +register: 0.476 +virtual: 0.471 +arm: 0.439 +vnc: 0.435 +hypervisor: 0.410 +boot: 0.394 +mistranslation: 0.332 +risc-v: 0.327 +i386: 0.324 +permissions: 0.310 +assembly: 0.294 +TCG: 0.291 +debug: 0.252 +VMM: 0.244 +files: 0.212 +KVM: 0.172 + +qemu: Improve error reporting when migration can't connect + +Tested with upstream qemu as of Jun 3 2010 + +If the source qemu instance can't connect to the migration destination (say +there is no listening QEMU instance, or port is blocked by a firewall), all we +get is info migrate -> Migration status: failed. This is all we have to report +back to libvirt users if their firewall is misconfigured, which is crappy. + +Ideally, if we can't connect, migration would fail immediately with a relevant +message and strerror(). More info from 'info migrate' would be nice too, no +idea how this will play with QMP though. + +As a slightly related issue, try entering + +migrate tcp:127.0.0.0:6000 + +We get a 'migration failed' error, and then the monitor hangs! + +yep, it's been giving errors now for a while (and not hanging) and also recently gained the error text in 'info migrate': + +[dgilbert@dgilbert-t530 ~]$ /usr/bin/qemu-system-x86_64 -nographic +QEMU 2.10.1 monitor - type 'help' for more information +(qemu) migrate tcp:0:12345 +qemu-system-x86_64: Failed to connect socket: Connection refused +(qemu) info migrate +globals: store-global-state=1, only_migratable=0, send-configuration=1, send-section-footer=1 +capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off postcopy-ram: off x-colo: off release-ram: off block: off return-path: off +Migration status: failed (Failed to connect socket: Connection refused) +total time: 0 milliseconds +(qemu) + +So marking as fix-release + +(Note that there's a bug that causes a crash in the disconnect case on current head, but that's only been in for a week or so and I've just sent a fix for it). + diff --git a/results/classifier/118/graphic/599 b/results/classifier/118/graphic/599 new file mode 100644 index 000000000..532666f09 --- /dev/null +++ b/results/classifier/118/graphic/599 @@ -0,0 +1,41 @@ +graphic: 0.837 +device: 0.708 +boot: 0.663 +ppc: 0.586 +socket: 0.291 +semantic: 0.253 +files: 0.208 +vnc: 0.184 +risc-v: 0.178 +register: 0.170 +PID: 0.138 +performance: 0.131 +arm: 0.131 +network: 0.116 +mistranslation: 0.112 +user-level: 0.097 +architecture: 0.096 +debug: 0.084 +VMM: 0.081 +TCG: 0.077 +kernel: 0.070 +permissions: 0.069 +x86: 0.059 +i386: 0.049 +virtual: 0.043 +assembly: 0.041 +peripherals: 0.029 +hypervisor: 0.025 +KVM: 0.012 + +Q35: Windows BSOD running on 6.1.0 +Description of problem: +Starting with QEMU 6.1.0, Windows no longer boots with Q35 (including `pc-q35-6.0` as well). When booting an existing Windows 7 installation, BSOD appears during boot (0x0000007B). If you try to install Windows from an ISO, the follow error appears when you try to start setup. + + + +Other people also reported similar issues booting Windows 10, as well as during use of Windows XP. +Steps to reproduce: +Enter commands from above. +Additional information: +This was not an issue in QEMU 6.0.0. I can reproduce it at `master`. diff --git a/results/classifier/118/graphic/601 b/results/classifier/118/graphic/601 new file mode 100644 index 000000000..f6545e3ea --- /dev/null +++ b/results/classifier/118/graphic/601 @@ -0,0 +1,50 @@ +graphic: 0.872 +device: 0.854 +ppc: 0.816 +PID: 0.693 +performance: 0.684 +semantic: 0.649 +network: 0.604 +permissions: 0.556 +architecture: 0.545 +debug: 0.490 +files: 0.435 +vnc: 0.387 +arm: 0.386 +user-level: 0.379 +socket: 0.379 +TCG: 0.340 +risc-v: 0.333 +register: 0.326 +VMM: 0.291 +hypervisor: 0.284 +mistranslation: 0.277 +boot: 0.260 +peripherals: 0.244 +virtual: 0.238 +assembly: 0.159 +x86: 0.134 +kernel: 0.100 +i386: 0.081 +KVM: 0.018 + +import tensorflow causes qemu: uncaught target signal 6 (Aborted) - core dumped +Description of problem: +Crashes when importing tensorflow in Docker container under --platorm linux/amd64 on M1 Mac +``` +2021-09-06 13:35:24.435613: F tensorflow/core/lib/monitoring/sampler.cc:42] Check failed: bucket_limits_[i] > bucket_limits_[i - 1] (0 vs. 10) +qemu: uncaught target signal 6 (Aborted) - core dumped +``` +Steps to reproduce: +See https://gitlab.com/ryan-feather/docker-tensorflow-qemu-bug/ for Dockerfile and description of steps repeating here. +1. Using the dockerfile +``` +FROM python:3.9-buster +RUN pip install tensorflow==2.6.0 + +``` +2. `docker buildx build --iidfile build.id --platform linux/amd64 . --progress=plain` +3. ``` docker run --platform linux/amd64 `cat build.id` python -c "import tensorflow"``` +Additional information: +See +https://github.com/docker/for-mac/issues/5342 where the Docker team suggests this is a qemu bug. I couldn't find where anyone had opened one of these here, so hopefully this isn't a duplicate. diff --git a/results/classifier/118/graphic/610 b/results/classifier/118/graphic/610 new file mode 100644 index 000000000..61544606a --- /dev/null +++ b/results/classifier/118/graphic/610 @@ -0,0 +1,61 @@ +graphic: 0.958 +device: 0.928 +virtual: 0.917 +PID: 0.900 +vnc: 0.882 +VMM: 0.880 +semantic: 0.835 +ppc: 0.831 +files: 0.828 +user-level: 0.805 +assembly: 0.786 +arm: 0.778 +debug: 0.774 +performance: 0.766 +architecture: 0.757 +socket: 0.740 +register: 0.738 +network: 0.737 +permissions: 0.699 +risc-v: 0.687 +hypervisor: 0.686 +peripherals: 0.593 +kernel: 0.544 +boot: 0.538 +TCG: 0.508 +i386: 0.501 +mistranslation: 0.469 +KVM: 0.469 +x86: 0.436 + +after upgrade to 6.1.0, snapshot creation fails with "pre-save failed: qxl" +Description of problem: +When trying to create a snapshot using `virsh --connect qemu:///system snapshot-create-as <domain-name> <snapshot-name>` or virt-manager GUI, I get the following error: + +``` +Error: Error while writing VM state: Unknown error -1 + + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/details/snapshots.py", line 237, in _do_create_snapshot + self.vm.create_snapshot(xml) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1124, in create_snapshot + self._backend.snapshotCreateXML(xml, flags) + File "/usr/lib/python3.9/site-packages/libvirt.py", line 3059, in snapshotCreateXML + raise libvirtError('virDomainSnapshotCreateXML() failed') +libvirt.libvirtError: operation failed: Failed to take snapshot: pre-save failed: qxl +Error: Error while writing VM state: Unknown error -1 +``` +Additional information: +I'm using Arch Linux distro packages. +The issue appeared after upgrading qemu-headless from 6.0.0 to 6.1.0. +Downgrading back to 6.0.0 fixes the problem (snapshot are created +successfully and work as expected). + +In a reply to my message to libvirt-users describing the issue [1], +Daniel P. Berrangé confirmed that the error comes from QEMU and +recommended reporting it here. + +[1] https://listman.redhat.com/archives/libvirt-users/2021-September/msg00007.html diff --git a/results/classifier/118/graphic/612677 b/results/classifier/118/graphic/612677 new file mode 100644 index 000000000..314c54870 --- /dev/null +++ b/results/classifier/118/graphic/612677 @@ -0,0 +1,53 @@ +graphic: 0.996 +x86: 0.971 +user-level: 0.959 +ppc: 0.953 +architecture: 0.951 +device: 0.921 +boot: 0.900 +semantic: 0.888 +performance: 0.882 +mistranslation: 0.860 +files: 0.828 +kernel: 0.827 +register: 0.822 +debug: 0.820 +permissions: 0.791 +PID: 0.781 +network: 0.775 +TCG: 0.768 +arm: 0.761 +vnc: 0.747 +VMM: 0.714 +socket: 0.699 +risc-v: 0.698 +virtual: 0.686 +peripherals: 0.660 +hypervisor: 0.641 +i386: 0.636 +KVM: 0.605 +assembly: 0.507 + +qemu-kvm -curses displays garbled screen + +when I launch qemu-kvm -curses (even without a guest OS) I get a garbled output, here's a screenshot: +http://kontsevoy.com/qemu.png + +some more info: + +myarch ~: uname -a +Linux myarch 2.6.34-ARCH #1 SMP PREEMPT Mon Jul 5 22:12:11 CEST 2010 x86_64 Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz GenuineIntel GNU/Linux + +myarch ~: qemu-kvm --version +QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard + +I also fetched the latest qemu-kvm from git repo and compiled it with simple ./configure&make +The compiled version behaved similarly + +I also tried different terminal emulators: gnome-terminal and xterm - same thing +I also tried real terminal (i.e. booted without X) - same thing + +I can not reproduce this issue using -curses with the latest version of qemu, so I guess this has been fixed somewhen during the last years ... if nobody else can reproduce it, I think we should close this bug. + +I'm closing this bug now, since it is apparently working with the latest version of QEMU. + diff --git a/results/classifier/118/graphic/627 b/results/classifier/118/graphic/627 new file mode 100644 index 000000000..cdd493470 --- /dev/null +++ b/results/classifier/118/graphic/627 @@ -0,0 +1,37 @@ +graphic: 0.965 +performance: 0.798 +device: 0.793 +architecture: 0.491 +files: 0.401 +permissions: 0.355 +network: 0.342 +semantic: 0.297 +debug: 0.237 +risc-v: 0.201 +i386: 0.173 +peripherals: 0.154 +vnc: 0.129 +x86: 0.107 +register: 0.097 +kernel: 0.085 +socket: 0.081 +user-level: 0.080 +mistranslation: 0.078 +ppc: 0.077 +boot: 0.066 +VMM: 0.037 +TCG: 0.033 +arm: 0.025 +PID: 0.018 +assembly: 0.015 +virtual: 0.004 +hypervisor: 0.002 +KVM: 0.001 + +VI.EXE crashes on start under QEMU; works under BOCHS +Description of problem: +vi.exe hangs on startup; can be verified to work in bochs +Steps to reproduce: +1. Run vi.exe from DOS prompt; hang is evident immediately as ~ ~ ~ ~ doesn't show up +Additional information: +Actual [vi.exe](/uploads/d77076b8187489253c6ad8f1ab3ec247/vi.exe) attached; it's ridiculously old; the kind of thing that belongs on archive.org; I think I actually own this copy program by inheritance; but if the copyright holder objects we'll have to take it down again. :( diff --git a/results/classifier/118/graphic/639 b/results/classifier/118/graphic/639 new file mode 100644 index 000000000..11b33b231 --- /dev/null +++ b/results/classifier/118/graphic/639 @@ -0,0 +1,31 @@ +graphic: 0.837 +risc-v: 0.759 +performance: 0.706 +device: 0.583 +mistranslation: 0.432 +semantic: 0.346 +permissions: 0.345 +TCG: 0.238 +peripherals: 0.218 +user-level: 0.217 +arm: 0.204 +vnc: 0.189 +VMM: 0.145 +network: 0.120 +files: 0.117 +virtual: 0.110 +register: 0.094 +ppc: 0.091 +architecture: 0.082 +debug: 0.078 +boot: 0.076 +PID: 0.069 +hypervisor: 0.060 +KVM: 0.050 +socket: 0.031 +i386: 0.023 +kernel: 0.019 +assembly: 0.014 +x86: 0.012 + +Crash using riscv.shakti.cclass.soc device diff --git a/results/classifier/118/graphic/640213 b/results/classifier/118/graphic/640213 new file mode 100644 index 000000000..bbb872321 --- /dev/null +++ b/results/classifier/118/graphic/640213 @@ -0,0 +1,58 @@ +graphic: 0.918 +x86: 0.915 +kernel: 0.908 +debug: 0.867 +semantic: 0.837 +architecture: 0.833 +performance: 0.792 +user-level: 0.791 +boot: 0.743 +files: 0.725 +device: 0.719 +mistranslation: 0.717 +permissions: 0.639 +network: 0.637 +ppc: 0.637 +PID: 0.622 +socket: 0.614 +vnc: 0.533 +VMM: 0.526 +risc-v: 0.523 +i386: 0.523 +register: 0.507 +hypervisor: 0.501 +assembly: 0.490 +peripherals: 0.484 +arm: 0.444 +KVM: 0.443 +TCG: 0.335 +virtual: 0.308 + +QEMU does not communicate properly with GDB with a 64 bit guest + +I have been trying to figure out why I cannot debug a 64 bit kernel of my own invention. + +I launch qemu-system-x86_64 with the -s -S flags, we also specify -cpu core2duo -vga std and a -hda with an ext2 FS holding our multiboot kernel and GRUB2. + +When I try to set breakpoints and "continue" in GDB (7.2) using the very latest HEAD (b6601141cd2a170dfe773987b06f716a190ea7e0) or 0.12.0 or 0.12.5 or 13.0.rc0 or 13.0.rc1, I get failures of the same nature: + +0x0000000000000000 in ?? () +(gdb) break main +Breakpoint 1 at 0x101730: file src/kernel/init.c, line 18. +(gdb) c + +Program received signal SIGTRAP, Trace/breakpoint trap. +0x0000000000000000 in ?? () +(gdb) + +Note that in this case, main lies in 64 bit mode. However, trying to break on _start yields virtually the same effect and _start is 32 bit code. + +By doing a git bisect, I managed to narrow the commit that introduced this bug to 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1. Reverting this commit on HEAD seemingly fixed the problem for both the 32 bit and 64 bit cases. +I might be doing something incorrectly on my end but this seemed to fix the problem. + +Perhaps the pertinent thing to do would be to revert 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1 as it seems to do nothing but break things unless, of course, this would only break something that I am not aware of further. + +Can you still reproduce this problem with the latest version of QEMU, or can we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/654 b/results/classifier/118/graphic/654 new file mode 100644 index 000000000..bc8fc99e7 --- /dev/null +++ b/results/classifier/118/graphic/654 @@ -0,0 +1,53 @@ +graphic: 0.937 +performance: 0.699 +semantic: 0.625 +device: 0.574 +architecture: 0.531 +ppc: 0.481 +peripherals: 0.464 +network: 0.459 +x86: 0.458 +files: 0.455 +i386: 0.417 +kernel: 0.410 +PID: 0.407 +user-level: 0.388 +permissions: 0.358 +vnc: 0.352 +risc-v: 0.328 +TCG: 0.314 +VMM: 0.302 +KVM: 0.291 +register: 0.290 +mistranslation: 0.284 +arm: 0.266 +debug: 0.266 +hypervisor: 0.264 +socket: 0.238 +virtual: 0.190 +boot: 0.146 +assembly: 0.077 + +Strace Log Output Mangled +Description of problem: +The syscall log entries from the strace logging capability can be interrupted by other log messages before the full syscall line is +complete. +This makes parsing the strace syscall lines from the log output difficult. +Steps to reproduce: +1. Run the supplied command with a simple dynamically linked binary, or a binary that performs mmaps +2. Notice that the strace 'mmap' syscall log entries in the trace file are interrupted by the page log output +Additional information: +I have attached an example log from a dynamically linked 'hello world' binary, which demonstrates the bug in the mmap syscall strace entries. [output.trace](/uploads/88c83273582d00241fbf95af735dcc61/output.trace) + + +I believe this bug caused by a couple of things: +Firstly, in the linux-user/syscall.c file: the strace syscall entry is not output atomically, but instead split across two calls: +The first half is at `print_syscall`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13153 +And the return value (and new line) is printed in `print_syscall_ret`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13160 + +In the case of the mmap syscall, the function `log_page_dump` is called between these two functions resulting in the mangled log output: +https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/mmap.c#L633 +There may be other syscalls that behave similarly, but this was noticed due to the mmap behavior. + + +Internally to the `print_syscall` and `print_syscall_ret` functions, `qemu_log` is called multiple times to compose the full log entry, and it seems that it is inside `qemu_log` that the logfile lock is obtained and dropped - so theoretically another thread can output to the log during the printing of a single syscall entry between these `qemu_log` calls. I do not know if this actually happens in practice besides the mmap scenario described above. diff --git a/results/classifier/118/graphic/661 b/results/classifier/118/graphic/661 new file mode 100644 index 000000000..235695562 --- /dev/null +++ b/results/classifier/118/graphic/661 @@ -0,0 +1,74 @@ +register: 0.977 +graphic: 0.971 +ppc: 0.921 +x86: 0.894 +performance: 0.845 +peripherals: 0.824 +kernel: 0.824 +user-level: 0.798 +network: 0.736 +socket: 0.730 +device: 0.722 +assembly: 0.719 +mistranslation: 0.715 +boot: 0.707 +debug: 0.690 +architecture: 0.690 +PID: 0.688 +semantic: 0.679 +permissions: 0.677 +files: 0.639 +vnc: 0.625 +risc-v: 0.622 +virtual: 0.601 +hypervisor: 0.595 +TCG: 0.565 +KVM: 0.545 +arm: 0.535 +VMM: 0.523 +i386: 0.508 + +Unable to enable 5 level paging +Description of problem: +When attempting to set cr4.LA57, qemu just freezes on that instruction. When I say freeze I mean literally freeze, no exceptions, nothing, it just halts forever on that instruction. When this happened, the first thing I did was + +``` +(qemu) info registers +EAX=00001000 EBX=00000001 ECX=80224f08 EDX=00000000 +ESI=8034a3a0 EDI=00026520 EBP=000079f8 ESP=000079c8 +EIP=00019648 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0020 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +CS =0018 00000000 ffffffff 00c09a00 DPL=0 CS32 [-R-] +SS =0020 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0020 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +FS =0020 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0020 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 0000e120 00000037 +IDT= 00000000 00000000 +CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +... +``` + +then using gdb to figure out what instruction it is hanging on, I set a breakpoint at 0x19648 at and ran +``` +(gdb) x/1 0x19648 +=> 0x19648: mov %rax,%cr4 +(gdb) +``` + +This instruction corresponds to this LOC within limine https://github.com/limine-bootloader/limine/blob/trunk/stage23/protos/stivale.32.c#L33 +Steps to reproduce: +1. Try to enable 5 level paging +2. qemu freezes when trying to set cr4.LA57 +3. cry +Additional information: +This never happened prior to version 6.1, I test this on multiple different machines and a few of my friends +experienced the same issue + +I have not tested this on linux, however I assume it will do the same on anything else. +Either way, qemu should not be just halting diff --git a/results/classifier/118/graphic/665743 b/results/classifier/118/graphic/665743 new file mode 100644 index 000000000..a011f7231 --- /dev/null +++ b/results/classifier/118/graphic/665743 @@ -0,0 +1,40 @@ +graphic: 0.916 +device: 0.447 +semantic: 0.210 +mistranslation: 0.147 +user-level: 0.134 +i386: 0.131 +x86: 0.072 +debug: 0.071 +register: 0.049 +architecture: 0.043 +vnc: 0.040 +peripherals: 0.037 +risc-v: 0.033 +performance: 0.032 +ppc: 0.031 +boot: 0.028 +virtual: 0.027 +PID: 0.026 +hypervisor: 0.023 +arm: 0.022 +assembly: 0.020 +permissions: 0.019 +files: 0.016 +TCG: 0.012 +VMM: 0.012 +socket: 0.012 +kernel: 0.008 +network: 0.006 +KVM: 0.003 + +Cocoa video corruption when guest uses RGB565 mode + +The cocoa video driver doesn't currently support when the guest uses RGB565 or HighColor mode resulting in corrupted video. The initial graphics screen of recent Ubuntu installs is an example. The attached patch against 0.13.0-release seems to fix the problem by introducing an indirect data provider that translates from RGB565 to RGB888, a mode that core graphics supports. + + + +Can you still reproduce this problem with the latest version of QEMU? If so, could you please rebase your patch to the latest git version and send it to the mailing list (see http://qemu-project.org/Contribute/SubmitAPatch for details)? Sorry, we do not take patches from the bugtracker, they always have got to be discussed on the qemu-devel mailing list first. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/668 b/results/classifier/118/graphic/668 new file mode 100644 index 000000000..ac66f323e --- /dev/null +++ b/results/classifier/118/graphic/668 @@ -0,0 +1,51 @@ +graphic: 0.950 +ppc: 0.910 +files: 0.880 +x86: 0.877 +device: 0.832 +user-level: 0.815 +debug: 0.805 +performance: 0.784 +risc-v: 0.781 +vnc: 0.744 +network: 0.730 +semantic: 0.728 +PID: 0.680 +arm: 0.662 +permissions: 0.645 +mistranslation: 0.645 +register: 0.641 +VMM: 0.629 +kernel: 0.620 +socket: 0.614 +TCG: 0.579 +boot: 0.551 +hypervisor: 0.537 +architecture: 0.511 +peripherals: 0.488 +i386: 0.449 +KVM: 0.399 +virtual: 0.352 +assembly: 0.249 + +No trace verbs +Description of problem: +I am trying to follow [this tutorial](https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver) to get my sound working again, but I am stuck at the step where I have to analyse the verbs, because I get none. They say I should get things similar to this: +``` +CORB[1] = 0xf0000 (caddr:0x0 nid:0x0 control:0xf00 param:0x0) +CORB[2] = 0xf0002 (caddr:0x0 nid:0x0 control:0xf00 param:0x2) +CORB[3] = 0xf0004 (caddr:0x0 nid:0x0 control:0xf00 param:0x4) +RIRBWP advance to 3, last WP 0 +CORB caddr:0x0 nid:0x0 control:0xf00 param:0x0 response:0x10ec0245 (ex 0x0) +CORB caddr:0x0 nid:0x0 control:0xf00 param:0x2 response:0x100001 (ex 0x0) +CORB caddr:0x0 nid:0x0 control:0xf00 param:0x4 response:0x10001 (ex 0x0) +``` +in the `qemu-output.txt` file, but instead I am getting [this](https://github.com/ryanprescott/realtek-verb-tools/files/7331986/qemu-output.txt) in the console. + +How do I get verbs in the first format ? + +I tried compiling qemu from source with this: `./configure --enable-trace-backends=log --target-list=x86_64-softmmu`, but that produced the same result as using the `qemu-system-x86_64` command that I got by installing qemu with my package manager. +Steps to reproduce: +https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver +Additional information: +I don't know, as me if I am missing something diff --git a/results/classifier/118/graphic/671 b/results/classifier/118/graphic/671 new file mode 100644 index 000000000..3daa99112 --- /dev/null +++ b/results/classifier/118/graphic/671 @@ -0,0 +1,48 @@ +graphic: 0.988 +virtual: 0.948 +kernel: 0.930 +device: 0.920 +ppc: 0.849 +KVM: 0.819 +peripherals: 0.790 +network: 0.782 +boot: 0.776 +PID: 0.764 +architecture: 0.745 +socket: 0.741 +arm: 0.741 +hypervisor: 0.728 +vnc: 0.727 +semantic: 0.704 +performance: 0.670 +TCG: 0.644 +register: 0.578 +debug: 0.555 +i386: 0.530 +risc-v: 0.520 +VMM: 0.497 +x86: 0.460 +mistranslation: 0.448 +permissions: 0.388 +files: 0.314 +user-level: 0.270 +assembly: 0.099 + +gtk with virtio and opengl black screen +Description of problem: +Running the provided command line, the screen is black, and the vm still starts. +I can confirm that turning off gl (with gl=off), everything works. + +These are line outputs printed out by QEMU: +``` +gl_version 45 - core profile enabled +vrend_renderer_fill_caps: Entering with stale GL error: 1280 +GLSL feature level 430 +virtio_input_hid_handle_status: unknown type 20 +virtio_input_hid_handle_status: unknown type 20 +``` +Steps to reproduce: +1. Execute the provided command +2. Wait +Additional information: +The bug was opened on launchpad by Ethan (ethannij). However, after the migration to github issues, the bug expired and no one reported here. This is the full launchpad discussion: https://bugs.launchpad.net/qemu/+bug/1898490 diff --git a/results/classifier/118/graphic/673 b/results/classifier/118/graphic/673 new file mode 100644 index 000000000..7fd35b1b0 --- /dev/null +++ b/results/classifier/118/graphic/673 @@ -0,0 +1,40 @@ +graphic: 0.973 +boot: 0.802 +device: 0.780 +kernel: 0.754 +files: 0.736 +vnc: 0.652 +network: 0.650 +architecture: 0.583 +ppc: 0.569 +i386: 0.560 +socket: 0.467 +TCG: 0.449 +x86: 0.448 +permissions: 0.422 +VMM: 0.415 +PID: 0.413 +register: 0.412 +risc-v: 0.394 +arm: 0.378 +KVM: 0.371 +debug: 0.365 +semantic: 0.345 +performance: 0.281 +peripherals: 0.260 +hypervisor: 0.240 +user-level: 0.181 +mistranslation: 0.133 +virtual: 0.120 +assembly: 0.043 + +I can no longer boot with -kernel and -initrd +Description of problem: +The kernel refuses to mount the initramfs and proceeds to kernel panic. i didnt have this problem until qemu updated +Steps to reproduce: +I have put it all in the git repo of my project +1. git clone https://github.com/oknowaen/ltl-initramfs.git +2. cd ltl-initramfs +3. make (will start automatically)! +Additional information: +[Screenshot_20211016_182355](/uploads/c04094f5bcccadc3f8473f2ea6fc864d/Screenshot_20211016_182355.png) diff --git a/results/classifier/118/graphic/674 b/results/classifier/118/graphic/674 new file mode 100644 index 000000000..297d1fbce --- /dev/null +++ b/results/classifier/118/graphic/674 @@ -0,0 +1,44 @@ +graphic: 0.853 +device: 0.791 +kernel: 0.763 +architecture: 0.716 +boot: 0.712 +socket: 0.702 +PID: 0.672 +files: 0.663 +mistranslation: 0.648 +arm: 0.642 +hypervisor: 0.635 +performance: 0.632 +risc-v: 0.624 +register: 0.610 +KVM: 0.608 +debug: 0.604 +vnc: 0.598 +semantic: 0.596 +virtual: 0.591 +VMM: 0.581 +permissions: 0.536 +network: 0.486 +TCG: 0.469 +ppc: 0.441 +x86: 0.435 +i386: 0.426 +user-level: 0.415 +assembly: 0.355 +peripherals: 0.353 + +Windows 7 fails with blue screen when KVM is enabled. +Description of problem: +The problem appeared immediately after a full system update of Arch Linux (The first for several months). Windows 7 images that had been running normally would fail with a blue screen and Error 0x7E immediately after displaying "Starting Windows". The same error would occur with a Windows 7 installation image, as in the command line above. When the "-enable-kvm" option was removed Windows would run normally but slowly. An old Clonezilla image booted without apparent problems. + +The final line on the blue screen reads: +*** STOP: 0x0000007E (0xC0000005,0x8BA3CA36,0x85186AA0,0x85186680) + +After getting the problem with the Arch package I cloned the source and built the latest version, getting the same error. However, when I build version 5.2.95 (v6.0.0-rc5-dirty) I found that this would run my existing Windows images (qcow2) and the installation ISO image. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/118/graphic/678363 b/results/classifier/118/graphic/678363 new file mode 100644 index 000000000..836211f61 --- /dev/null +++ b/results/classifier/118/graphic/678363 @@ -0,0 +1,50 @@ +graphic: 0.858 +mistranslation: 0.833 +device: 0.748 +performance: 0.721 +user-level: 0.598 +semantic: 0.596 +architecture: 0.456 +network: 0.316 +peripherals: 0.306 +ppc: 0.303 +permissions: 0.296 +assembly: 0.260 +i386: 0.255 +x86: 0.249 +socket: 0.224 +arm: 0.202 +boot: 0.197 +vnc: 0.176 +PID: 0.174 +register: 0.173 +risc-v: 0.167 +virtual: 0.163 +debug: 0.140 +TCG: 0.129 +VMM: 0.102 +files: 0.101 +kernel: 0.100 +hypervisor: 0.092 +KVM: 0.043 + +Swapping caps lock and control causes qemu confusion + +Running Fedora14 [host], I have caps-lock and control swapped over in my keyboard preferences. + +Qemu doesn't cope very well with this; running an OS inside Qemu (again fedora, suspect that it doesn't matter): + +The physical caps-lock key [which the host uses as control] toggles caps-lock on both press and release. + +The physical control key [which the host uses as caps-lock], acts as both a caps-lock and control key. + +Qemu should either respect my keyboard layout or else ignore it completely. + +Which interface is this? + +I suspect this behaves differently in GTK/SDL/... + +Also it seems to WorkForMe(tm) mostly. qemu tends to ignore the layout completely so installing same keymap in host and guest gives consistent result, and other configurations give inconsistent but correct result. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/680758 b/results/classifier/118/graphic/680758 new file mode 100644 index 000000000..1ef6bfb8f --- /dev/null +++ b/results/classifier/118/graphic/680758 @@ -0,0 +1,85 @@ +graphic: 0.820 +KVM: 0.713 +x86: 0.702 +performance: 0.660 +PID: 0.636 +ppc: 0.626 +device: 0.587 +socket: 0.576 +virtual: 0.505 +register: 0.401 +arm: 0.389 +peripherals: 0.383 +kernel: 0.380 +architecture: 0.369 +network: 0.358 +hypervisor: 0.338 +boot: 0.337 +vnc: 0.323 +semantic: 0.307 +mistranslation: 0.289 +i386: 0.278 +risc-v: 0.249 +user-level: 0.217 +VMM: 0.211 +debug: 0.202 +assembly: 0.176 +files: 0.158 +permissions: 0.155 +TCG: 0.144 + +balloon only resizes by 2M + +when in monitor and running balloon 512 from a 1024M VM, the vm dropped the size to 1020 (this value changes), then every subsequent request to balloon 512 will drop it by another 2M. The system was running at above 60% RAM free when these requests were made. also requesting to up the ram results in no change above 1024 (I'm guessing this is intentional, but was unable to find any documentation) + +Versions: + +qemu-kvm 0.13.0 +qemu-kvm.git b377474e589e5a1fe2abc7b13fafa8bad802637a + + +Qemu Command Line: + +./x86_64-softmmu/qemu-system-x86_64 -ees/seven.base,if=virtio -net nic,model=virtio,macaddr=02:00:00:00:00:01 -net tap,script=/etc/qemu/qemu-ifup,downscript=/etc/qemu/qemu-ifdown -vga std -usb -usbdevice tablet -rtc base=localtime,clock=host -watchdog i6300esb -balloon virtio -m 1024 -no-quit -smp 2 -monitor stdio + + +Monitor Session: + +QEMU 0.13.50 monitor - type 'help' for more information +(qemu) info balloon +balloon: actual=1024 +(qemu) balloon 1536 +(qemu) info balloon +balloon: actual=1024 +(qemu) balloon 512 +(qemu) info balloon +balloon: actual=1020 +(qemu) info balloon +balloon: actual=1020 +(qemu) balloon 512 +(qemu) info balloon +balloon: actual=1018 + +the same here: + +host debian squeeze: qemu-kvm-0.12.5 +guest: windows 2008 server +balloon driver: 6.1.7600.16385 10.8.2010 + + + + +~# virsh -c qemu:///system dominfo 9 | grep Used +Used memory: 2064384 kB +~# virsh -c qemu:///system setmem 9 512000 + +~# virsh -c qemu:///system dominfo 9 | grep Used +Used memory: 2062336 kB + + +the same host, but winXP guest with the same balloon driver is working, looks like balloon driver issue... + +Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU / the latest version of the balloon driver in the guest? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/686613 b/results/classifier/118/graphic/686613 new file mode 100644 index 000000000..97b063692 --- /dev/null +++ b/results/classifier/118/graphic/686613 @@ -0,0 +1,90 @@ +graphic: 0.876 +files: 0.858 +device: 0.848 +permissions: 0.822 +hypervisor: 0.819 +VMM: 0.814 +PID: 0.811 +arm: 0.808 +register: 0.806 +TCG: 0.804 +semantic: 0.799 +vnc: 0.795 +ppc: 0.794 +user-level: 0.793 +network: 0.792 +performance: 0.786 +debug: 0.785 +x86: 0.781 +assembly: 0.771 +socket: 0.769 +architecture: 0.758 +boot: 0.757 +risc-v: 0.752 +mistranslation: 0.749 +virtual: 0.739 +KVM: 0.732 +kernel: 0.706 +i386: 0.667 +peripherals: 0.635 + +USB MSD are not marked as removable + + Filed from Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=589130 + +Guests can access USB Mass Storage Device, but fail to mark them as removable. + +danpb has mentioned that Linux gets this information from SCSI INQUIRY response. So it's up to the USB Mass Storage Device to decide whether or not it wants to have a removable medium. + +The SCSI INQUIRY RMB (removable medium bit) tends to be set on modern USB Mass Storage Devices. Of course they don't actually have a removable medium. + +One side-effect of setting this bit is that Windows Auto-Run will work if RMB=0 but not work if RMB=0. Also, on RMB=1 devices only the first partition is displayed by Windows - you can't have more than one partition on the device. + +For more information, see: http://www.microsoft.com/whdc/connect/usb/usbfaq.mspx + +So at the end of the day, it's up to QEMU whether or not to mark USB MSDs as having removable media. Since modern devices tend to set RMB=1, we probably should too. + +"One side-effect of setting this bit is that Windows Auto-Run will work if RMB=0 but not work if RMB=0" should read "but not work if RMB=1". + +A sampling of physical USB devices: +1. Noname 2GB USB stick: RMB=1 +2. Nexus One USB storage: RMB=1 +3. LaCie USB harddisk: RMB=0 + +I suspect there's no setting that will satisfy everyone here. It makes sense for a USB harddisk to set RMB=0 because that allows you to put on more than one partition under Windows. + +Stefan, you fixed this in QEMU 24 Jan 2011 so this bug can be marked as Fixed Released? + +SEE: http://lists.gnu.org/archive/html/qemu-devel/2011-01/msg02425.html +Append ",removable=on" to a device definition for USB Mass Storage Devices to override the removable bit (but off by default): +> qemu -usb +> -drive if=none,file=test.img,cache=none,id=disk0 +> -device usb-storage,drive=disk0,removable=on + +However, I cannot see a way to set "removable=on" for usb-storage devices started via libvirt (in 12.04, with libvirt-bin 0.9.8-2ubuntu17.1 and virt-manager 0.9.1-1ubuntu5.1). + +So, is a feature request required for virt-manager to expose this option for virtual disks (default to 'on' for bus='usb') and add support to libvirt's XML to set "removable=on" ? + +On Mon, Jul 2, 2012 at 4:04 PM, Sebastian Malcolm +<email address hidden> wrote: +> Stefan, you fixed this in QEMU 24 Jan 2011 so this bug can be marked as +> Fixed Released? + +Yes + +> However, I cannot see a way to set "removable=on" for usb-storage +> devices started via libvirt (in 12.04, with libvirt-bin +> 0.9.8-2ubuntu17.1 and virt-manager 0.9.1-1ubuntu5.1). +> +> So, is a feature request required for virt-manager to expose this option +> for virtual disks (default to 'on' for bus='usb') and add support to +> libvirt's XML to set "removable=on" ? + +Yes, I just checked libvirt.git/master and cannot see a way to set the +removable option. I'm afraid libvirt also needs changes. + +Stefan + + +Setting status to "Fix released" according to comment #5 (if there is something left to do for libvirt, please consult their bugtracker instead) + diff --git a/results/classifier/118/graphic/691 b/results/classifier/118/graphic/691 new file mode 100644 index 000000000..5b929c20a --- /dev/null +++ b/results/classifier/118/graphic/691 @@ -0,0 +1,36 @@ +graphic: 0.964 +device: 0.827 +network: 0.778 +vnc: 0.575 +semantic: 0.525 +register: 0.487 +architecture: 0.455 +performance: 0.446 +files: 0.429 +debug: 0.419 +peripherals: 0.341 +permissions: 0.298 +socket: 0.285 +boot: 0.239 +hypervisor: 0.231 +arm: 0.227 +mistranslation: 0.193 +PID: 0.186 +risc-v: 0.184 +kernel: 0.166 +virtual: 0.165 +user-level: 0.159 +i386: 0.133 +TCG: 0.128 +VMM: 0.124 +ppc: 0.109 +x86: 0.094 +assembly: 0.040 +KVM: 0.016 + +`-nic model=help` on qemu-system-riscv64 doesn't output supported models +Description of problem: +`-nic model=help` doesn't list out the supported NIC models and instead launches QEMU with warnings. + +Steps to reproduce: +1. run `qemu-system-riscv64 -machine virt -nic model=help` diff --git a/results/classifier/118/graphic/694 b/results/classifier/118/graphic/694 new file mode 100644 index 000000000..d43d65a84 --- /dev/null +++ b/results/classifier/118/graphic/694 @@ -0,0 +1,31 @@ +architecture: 0.988 +graphic: 0.927 +device: 0.767 +arm: 0.467 +risc-v: 0.459 +debug: 0.421 +ppc: 0.421 +vnc: 0.250 +network: 0.205 +TCG: 0.177 +PID: 0.168 +user-level: 0.162 +performance: 0.150 +semantic: 0.149 +VMM: 0.148 +permissions: 0.138 +virtual: 0.133 +register: 0.117 +files: 0.111 +socket: 0.084 +hypervisor: 0.054 +kernel: 0.051 +mistranslation: 0.047 +peripherals: 0.032 +assembly: 0.032 +KVM: 0.011 +boot: 0.007 +x86: 0.006 +i386: 0.002 + +Crash using MIPS I7200 CPU with non-nanoMIPS ELF diff --git a/results/classifier/118/graphic/696 b/results/classifier/118/graphic/696 new file mode 100644 index 000000000..7a84be123 --- /dev/null +++ b/results/classifier/118/graphic/696 @@ -0,0 +1,39 @@ +graphic: 0.935 +device: 0.859 +mistranslation: 0.793 +semantic: 0.790 +performance: 0.702 +vnc: 0.695 +architecture: 0.645 +PID: 0.605 +files: 0.537 +VMM: 0.532 +socket: 0.521 +risc-v: 0.518 +ppc: 0.469 +debug: 0.463 +TCG: 0.430 +kernel: 0.422 +register: 0.401 +network: 0.396 +arm: 0.380 +user-level: 0.364 +boot: 0.350 +i386: 0.328 +hypervisor: 0.317 +x86: 0.313 +permissions: 0.262 +virtual: 0.256 +peripherals: 0.250 +KVM: 0.206 +assembly: 0.062 + +EDID does not reflected to window size when added through the commandline +Description of problem: +It seems some odd behavior on the guest screen. it shows me the size of default window (640x480) instead of override the value to 1740x720. This size (640x480) is first initialized on ui/console.c => QemuConsole *graphic_console_init and I did noticed that in hw/display/virtio-gpu-base.c=> static int virtio_gpu_ui_info the override value is not taking place instead it just took the value from ui/console.c (640x480). May I know, how do I achieved the right override edid value from the current provided interface. + +##Additional information +I did noticed that the edid flag is always true (running this command) It is contradiction from the doc. +Steps to reproduce: +1. Run the qemu with the command mentioned +2. Check the resolution of guest OS diff --git a/results/classifier/118/graphic/707 b/results/classifier/118/graphic/707 new file mode 100644 index 000000000..82e6838b8 --- /dev/null +++ b/results/classifier/118/graphic/707 @@ -0,0 +1,92 @@ +graphic: 0.942 +VMM: 0.934 +virtual: 0.910 +architecture: 0.765 +x86: 0.753 +device: 0.740 +files: 0.730 +performance: 0.727 +kernel: 0.718 +permissions: 0.673 +vnc: 0.653 +semantic: 0.641 +hypervisor: 0.599 +register: 0.552 +network: 0.521 +KVM: 0.514 +TCG: 0.499 +PID: 0.496 +user-level: 0.472 +mistranslation: 0.470 +socket: 0.462 +risc-v: 0.408 +ppc: 0.368 +peripherals: 0.328 +debug: 0.309 +boot: 0.297 +arm: 0.296 +i386: 0.248 +assembly: 0.235 + +The QEMU emulator incorrectly interprets the contents of the SLIC table. See attached image. +Description of problem: +The QEMU emulator incorrectly interprets the contents of the SLIC table. + +The SLIC table read on pure hardware and in a virtual machine in the fedora 34 and 35: + + +Steps to reproduce: +Steps to Reproduce: + +1. Install Fedora 34 + +2. Install virtualization group: + + dnf group install virtualization + +4. Place SLIC binary image(slic.bin) into the direcrory /var/lib/libvirt/images + +3. Create Virtual Machine with Virtual Machine Manager. + +4. Modify xml description of virtual machine: + `... + <os> + ... + <acpi> + <table type='slic'>/var/lib/libvirt/images/slic.bin</table> + </acpi> + </os> + ...` + +5. Install Microsoft Windows 7 64-bit into Virtual machine. + +6. Place sertificate into Windows 7. + +7. Run with admin rights: + + slmgr.vbs /ilc <sertificate> + slmgr.vbs /ipk <key> + +8. Windows 7 will be activated ! + +9. Save Virtual Machine Image and it's xml description anywere. + +10. Install Fedora 35 + +11. Install virtualization group. + +12. Place saved Virtual Machine Image and slic.bin into the directory /var/lib/libvirt/images/ + +13. Register virtual machine: + + virsh -c qemu:///system define <xml_file> + +15. Run virtual machine - Windows 7 will lose it activation. +Additional information: +Fedora 34 has: + kernel-5.14.15-200.fc34.x86_64, qemu-system-x86-5.2.0-8.fc34.x86_64 + +Fedora 35 has: + kernel-5.14.15-300.fc35.x86_64, qemu-system-x86-6.1.0-9.fc35.x86_64 + +Slick Binary Image: [slic.bin](/uploads/da94a96516c3dbe52803fb84738f434c/slic.bin) diff --git a/results/classifier/118/graphic/709584 b/results/classifier/118/graphic/709584 new file mode 100644 index 000000000..19e6bd127 --- /dev/null +++ b/results/classifier/118/graphic/709584 @@ -0,0 +1,56 @@ +graphic: 0.876 +device: 0.794 +ppc: 0.768 +architecture: 0.536 +x86: 0.534 +user-level: 0.516 +semantic: 0.492 +performance: 0.444 +permissions: 0.415 +mistranslation: 0.400 +vnc: 0.386 +register: 0.382 +PID: 0.346 +socket: 0.318 +kernel: 0.238 +i386: 0.235 +arm: 0.202 +hypervisor: 0.199 +risc-v: 0.197 +debug: 0.171 +boot: 0.165 +assembly: 0.162 +peripherals: 0.125 +network: 0.115 +files: 0.095 +VMM: 0.056 +TCG: 0.049 +KVM: 0.031 +virtual: 0.026 + +Fullscreen mode splits screen over monitor boundaries on dual-monitor system + +I originally reported this for the Android SDK emulator, which is built on QEMU: http://code.google.com/p/android/issues/detail?id=14336 + +Can confirm that this bug is present in stock QEMU shipped with Ubuntu 10.10: +QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard + +Steps to reproduce: +- get a Linux machine with multiple-monitor setup (tested using NVidia proprietary driver on Ubuntu 10.10 x86_64, with two monitors side-by-side in 'TwinView' configuration) +- launch qemu +- hit ctrl+alt+f to go into fullscreen mode + +Expected behavior: +- emulator should take over one screen (either the first screen, largest screen, or screen the emulator is presently on) +- emulator's display should center or scale to fit within available area of the taken-over screen + +Actual behavior: +- emulator takes over both screens +- emulator's display is split over the boundary between the two screens + +I have the exactly the same problem/behavior. You are not allone! + +QEMU 0.12 is completely outdated nowadays ... can you still reproduce this issue with the latest version of QEMU (currently v2.8)? If yes, which graphical backend are you using? SDL1? SDL2? GTK? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/711 b/results/classifier/118/graphic/711 new file mode 100644 index 000000000..9e16d2509 --- /dev/null +++ b/results/classifier/118/graphic/711 @@ -0,0 +1,31 @@ +graphic: 0.848 +device: 0.818 +performance: 0.776 +risc-v: 0.626 +boot: 0.574 +arm: 0.475 +virtual: 0.308 +mistranslation: 0.271 +semantic: 0.269 +permissions: 0.174 +vnc: 0.145 +user-level: 0.075 +ppc: 0.074 +i386: 0.073 +VMM: 0.065 +peripherals: 0.047 +x86: 0.035 +network: 0.018 +register: 0.014 +socket: 0.014 +assembly: 0.014 +TCG: 0.012 +files: 0.009 +architecture: 0.009 +PID: 0.007 +KVM: 0.007 +hypervisor: 0.006 +debug: 0.005 +kernel: 0.003 + +ATI Rage video card emulation diff --git a/results/classifier/118/graphic/712 b/results/classifier/118/graphic/712 new file mode 100644 index 000000000..712f5357d --- /dev/null +++ b/results/classifier/118/graphic/712 @@ -0,0 +1,44 @@ +graphic: 0.868 +device: 0.854 +network: 0.721 +PID: 0.676 +semantic: 0.643 +socket: 0.615 +vnc: 0.593 +mistranslation: 0.593 +risc-v: 0.576 +debug: 0.571 +ppc: 0.562 +architecture: 0.518 +boot: 0.490 +VMM: 0.485 +arm: 0.431 +files: 0.419 +TCG: 0.407 +kernel: 0.398 +register: 0.387 +performance: 0.374 +user-level: 0.374 +hypervisor: 0.367 +i386: 0.364 +peripherals: 0.339 +x86: 0.319 +KVM: 0.288 +assembly: 0.254 +virtual: 0.141 +permissions: 0.075 + +Build fails if build directory name includes a comma +Description of problem: +Builds fail if the build directory name contains a comma. +Steps to reproduce: +1. `mkdir build,demo && cd build,demo` +2. `../configure && make` + +The linker fails because it uses a wrong build path (comma and trailing part of directory name is missing): + +``` +ld: can't read -exported_symbols_list file: /Users/stefan/src/gitlab/qemu-project/qemu/build +clang: error: linker command failed with exit code 1 (use -v to see invocation) +ninja: build stopped: subcommand failed. +``` diff --git a/results/classifier/118/graphic/716 b/results/classifier/118/graphic/716 new file mode 100644 index 000000000..04b37daaf --- /dev/null +++ b/results/classifier/118/graphic/716 @@ -0,0 +1,33 @@ +graphic: 0.958 +virtual: 0.936 +debug: 0.928 +device: 0.862 +arm: 0.825 +semantic: 0.733 +architecture: 0.644 +VMM: 0.629 +ppc: 0.501 +vnc: 0.493 +network: 0.415 +mistranslation: 0.350 +boot: 0.316 +hypervisor: 0.312 +performance: 0.310 +PID: 0.302 +KVM: 0.292 +risc-v: 0.286 +assembly: 0.252 +TCG: 0.244 +socket: 0.237 +permissions: 0.233 +kernel: 0.231 +peripherals: 0.230 +user-level: 0.176 +register: 0.162 +files: 0.160 +i386: 0.022 +x86: 0.016 + +using "-device scsi-cd" option on arm64 platform +Description of problem: +When using OpenStack to create a virtual machine instance, I need to configure the password of the root user through cloud-init. I use the ConfigDriver method, in which OpenStack will mount a virtual disk in iso9660 format to the virtual machine instance. The command line generated by OpenStack is shown above. You can see that this ConfigDrive virtual disk is mounted via "--device scsi-cd". But when I entered the virtual machine instance and used lsblk, blkid and searched in /dev/disk/by-label, I did not find the virtual disk that should be mounted. In addition, I don't have more debugging messages or error messages. I want to know if the "scsi-cd" is not fully adapted to arm64 platform. diff --git a/results/classifier/118/graphic/717 b/results/classifier/118/graphic/717 new file mode 100644 index 000000000..335d26cb0 --- /dev/null +++ b/results/classifier/118/graphic/717 @@ -0,0 +1,33 @@ +graphic: 0.966 +debug: 0.943 +virtual: 0.941 +device: 0.868 +arm: 0.829 +semantic: 0.783 +architecture: 0.684 +VMM: 0.647 +ppc: 0.549 +vnc: 0.495 +network: 0.443 +mistranslation: 0.365 +PID: 0.357 +hypervisor: 0.341 +boot: 0.336 +performance: 0.333 +assembly: 0.329 +KVM: 0.309 +risc-v: 0.309 +permissions: 0.301 +socket: 0.287 +kernel: 0.264 +TCG: 0.258 +peripherals: 0.245 +user-level: 0.235 +register: 0.204 +files: 0.182 +i386: 0.029 +x86: 0.020 + +using the "scsi-cd" option on arm64 platform +Description of problem: +When using OpenStack to create a virtual machine instance, I need to configure the password of the root user through cloud-init. I use the ConfigDriver method, in which OpenStack will mount a virtual disk in iso9660 format to the virtual machine instance. The command line generated by OpenStack is shown above. You can see that this ConfigDrive virtual disk is mounted via "--device scsi-cd". But when I entered the virtual machine instance and used lsblk, blkid and searched in /dev/disk/by-label, I did not find the virtual disk that should be mounted. In addition, I don't have more debugging messages or error messages. I want to know if the "scsi-cd" is not fully adapted to arm64 platform. diff --git a/results/classifier/118/graphic/731 b/results/classifier/118/graphic/731 new file mode 100644 index 000000000..ac9717b66 --- /dev/null +++ b/results/classifier/118/graphic/731 @@ -0,0 +1,51 @@ +graphic: 0.985 +device: 0.921 +mistranslation: 0.845 +virtual: 0.840 +hypervisor: 0.839 +architecture: 0.834 +files: 0.820 +KVM: 0.800 +register: 0.792 +semantic: 0.768 +PID: 0.749 +peripherals: 0.744 +debug: 0.723 +permissions: 0.714 +performance: 0.657 +assembly: 0.653 +VMM: 0.647 +user-level: 0.642 +vnc: 0.601 +socket: 0.600 +ppc: 0.580 +network: 0.570 +risc-v: 0.529 +boot: 0.498 +arm: 0.497 +x86: 0.469 +kernel: 0.465 +TCG: 0.457 +i386: 0.414 + +Display resolution fixed by 800x600 with latest VirtIO drivers and guest additions +Description of problem: +Display resolution can't be changed to anything else than 800x600. +Steps to reproduce: +1. Install qemu/kvm +2. Create virtual machine +3. Setup Windows 10 +4. Install VirtIO-Drivers +5. Install guest-agent +6. Install qxl-drivers + +Steps 5 and 6 enable use of QXL-Display, but do not lead to allow for higher display resolutions than before. +Additional information: + + + +Screen resolution is fixed by 800x600. +Driver is installed, but seems to have a problem (Attention sign. Warning, Error: digital signatur could not be checked -- at least there is no how to to make the existing signature work). +Latest available VirtIO-drivers where used as available from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso + +Older available drivers did not work too as expected. Same problem. Could not check older Windows 10 versions, because of lack of older install media. diff --git a/results/classifier/118/graphic/734 b/results/classifier/118/graphic/734 new file mode 100644 index 000000000..0a265a65f --- /dev/null +++ b/results/classifier/118/graphic/734 @@ -0,0 +1,58 @@ +architecture: 0.944 +graphic: 0.932 +debug: 0.918 +mistranslation: 0.910 +performance: 0.893 +kernel: 0.870 +semantic: 0.846 +arm: 0.815 +ppc: 0.810 +device: 0.780 +network: 0.774 +user-level: 0.764 +register: 0.759 +i386: 0.752 +vnc: 0.737 +hypervisor: 0.734 +PID: 0.733 +peripherals: 0.715 +risc-v: 0.709 +VMM: 0.708 +permissions: 0.700 +assembly: 0.697 +files: 0.684 +x86: 0.679 +TCG: 0.671 +socket: 0.623 +virtual: 0.559 +boot: 0.470 +KVM: 0.427 + +aarch64 tlb range invalidate is not accurate +Description of problem: +In this (https://gitlab.com/qemu-project/qemu/-/commit/84940ed82552d3c7c7327c83076b02cee7978257) commit, tlb range invalidate support is added, and I think qemu's range calculation is wrong. + +In `tlbi_aa64_range_get_length` function, `num`, `scale`, `page_size_granule` is caculated as below. + + +``` + num = extract64(value, 39, 4); + scale = extract64(value, 44, 2); + page_size_granule = extract64(value, 46, 2); + + page_shift = page_size_granule * 2 + 12; +``` + +As [Arm documentation](https://developer.arm.com/documentation/ddi0595/2021-06/AArch64-Instructions/TLBI-RVALE1--TLBI-RVALE1NXS--TLB-Range-Invalidate-by-VA--Last-level--EL1), NUM bits's length is 5, but the code above only extract 4bits. + +And `page_shift` also should be calculated as `(page_size_granule-1) <<1) + 12` rather than `page_size_granule * 2 + 12`. +Steps to reproduce: +1. +2. +3. +Additional information: +I found this issue while debugging a phenomenon that kernel panic occurs randomly in my qemu fork. + +I'm pretty sure this is one of the causes, but even if I roughly correct it, my problem has not been solved. + +I think my problem is TLB invalidate related issue, so if I find any more problems, I'll comment here. diff --git a/results/classifier/118/graphic/740 b/results/classifier/118/graphic/740 new file mode 100644 index 000000000..e025825d7 --- /dev/null +++ b/results/classifier/118/graphic/740 @@ -0,0 +1,57 @@ +graphic: 0.967 +performance: 0.966 +device: 0.928 +architecture: 0.862 +peripherals: 0.841 +PID: 0.821 +user-level: 0.803 +debug: 0.798 +socket: 0.781 +ppc: 0.776 +semantic: 0.760 +files: 0.758 +permissions: 0.715 +register: 0.682 +boot: 0.671 +network: 0.655 +kernel: 0.635 +arm: 0.613 +vnc: 0.583 +TCG: 0.573 +VMM: 0.549 +mistranslation: 0.468 +risc-v: 0.454 +assembly: 0.411 +hypervisor: 0.395 +i386: 0.280 +virtual: 0.253 +KVM: 0.061 +x86: 0.027 + +on single core Raspberry Pi, qemu-system-sparc appears to hang in bios +Description of problem: +I suspect it to be a race condition related to running on the slow single core Raspberry Pi, as I haven't managed to reproduce on x86 even when using taskset to tie qemu to a single core. + +The problem occurs about 4 out of 5 runs on qemu 5.2 (raspbian bullseye) and so far 100% of the time on qemu 6.1. + +About five seconds after start the sparc bios gets as far as `ttya initialized` and then appears to hang indefinitely. + +Instead, it should continue after about 3 more seconds with: +``` +Probing Memory Bank #0 32 Megabytes +Probing Memory Bank #1 Nothing there +Probing Memory Bank #2 Nothing there +Probing Memory Bank #3 Nothing there +``` + +See below for workaround. +Steps to reproduce: +1. Need a single core Raspberry Pi running raspbian, such as Raspberry Pi 1 or Zero +2. Download ss5.bin from https://github.com/andarazoroflove/sparc/raw/master/ss5.bin +3. Run the command: +``` +qemu-system-sparc -m 32 -bios ss5.bin -nographic +``` +After about 5 seconds of output it hangs at `ttya initialized` +Additional information: +## diff --git a/results/classifier/118/graphic/755 b/results/classifier/118/graphic/755 new file mode 100644 index 000000000..8db2f2d16 --- /dev/null +++ b/results/classifier/118/graphic/755 @@ -0,0 +1,89 @@ +graphic: 0.923 +peripherals: 0.892 +semantic: 0.885 +hypervisor: 0.884 +permissions: 0.871 +performance: 0.865 +debug: 0.865 +user-level: 0.863 +register: 0.858 +mistranslation: 0.854 +ppc: 0.848 +arm: 0.842 +assembly: 0.836 +VMM: 0.829 +virtual: 0.828 +PID: 0.820 +architecture: 0.820 +device: 0.818 +socket: 0.818 +TCG: 0.817 +boot: 0.790 +KVM: 0.781 +x86: 0.770 +vnc: 0.761 +risc-v: 0.756 +network: 0.714 +files: 0.711 +kernel: 0.708 +i386: 0.513 + +Qemu is stuck on the startup intermittently. +Description of problem: +Qemu is stuck on the startup intermittently. + +We are using kubevirt to launch the VM in kubernetes env. We have compiled qemu with a few flags enabled and using it. +All things are working as expected except we are seeing qemu stuck issue during VM startup. Please find logs from system in additional information + +Qemu version: qemu-system-x86-core-5.1.0-9.fc32.x86_64.rpm +Libvirtd version: 6.6.0 +Steps to reproduce: +1. Create and start a VM. +Additional information: +TOP OUTPUT: +-------------- +``` + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + **125 qemu 0 -20 8519896 73392 15412 R 99.9 0.1 85:27.96 CPU 0/KVM ** + 113 qemu 20 0 8519896 73392 15412 S 0.0 0.1 0:00.14 qemu-system-ori + 121 qemu 20 0 8519896 73392 15412 S 0.0 0.1 0:00.00 qemu-system-ori + 122 qemu 20 0 8519896 73392 15412 S 0.0 0.1 0:00.00 IO iothread1 + 124 qemu 20 0 8519896 73392 15412 S 0.0 0.1 0:00.23 IO mon_iothread + 126 qemu 0 -20 8519896 73392 15412 S 0.0 0.1 0:00.00 CPU 1/KVM + 128 qemu 20 0 8519896 73392 15412 S 0.0 0.1 0:00.00 vnc_worker +``` + +qemu logs on error: +------------------- +``` +KVM: injection failed, MSI lost (Operation not permitted) +KVM: injection failed, MSI lost (Operation not permitted) +KVM: injection failed, MSI lost (Operation not permitted) +KVM: injection failed, MSI lost (Operation not permitted) +KVM: injection failed, MSI lost (Operation not permitted) +KVM: injection failed, MSI lost (Operation not permitted) +KVM: injection failed, MSI lost (Operation not permitted) +``` + +dmesg logs from host:- +---------------------- +``` +[ 7853.643187] kvm: apic: phys broadcast and lowest prio +[ 7853.643265] kvm: apic: phys broadcast and lowest prio +[ 7853.643341] kvm: apic: phys broadcast and lowest prio +[ 7853.643413] kvm: apic: phys broadcast and lowest prio +[ 7853.643486] kvm: apic: phys broadcast and lowest prio +[ 7853.643559] kvm: apic: phys broadcast and lowest prio +[ 7853.643631] kvm: apic: phys broadcast and lowest prio +[ 7853.643703] kvm: apic: phys broadcast and lowest prio +[ 7853.643776] kvm: apic: phys broadcast and lowest prio +[ 7853.643848] kvm: apic: phys broadcast and lowest prio +[ 7853.643920] kvm: apic: phys broadcast and lowest prio +[ 7853.643992] kvm: apic: phys broadcast and lowest prio +[ 7853.644065] kvm: apic: phys broadcast and lowest prio +[ 7853.644137] kvm: apic: phys broadcast and lowest prio +[ 7853.644209] kvm: apic: phys broadcast and lowest prio +[ 7853.644289] kvm: apic: phys broadcast and lowest prio +``` + +--> diff --git a/results/classifier/118/graphic/758 b/results/classifier/118/graphic/758 new file mode 100644 index 000000000..de4635d8d --- /dev/null +++ b/results/classifier/118/graphic/758 @@ -0,0 +1,76 @@ +graphic: 0.937 +permissions: 0.915 +debug: 0.899 +performance: 0.890 +semantic: 0.878 +risc-v: 0.874 +peripherals: 0.869 +TCG: 0.863 +device: 0.863 +architecture: 0.861 +register: 0.861 +VMM: 0.850 +KVM: 0.845 +vnc: 0.842 +x86: 0.837 +arm: 0.833 +assembly: 0.826 +virtual: 0.822 +mistranslation: 0.820 +network: 0.819 +user-level: 0.801 +hypervisor: 0.801 +files: 0.793 +ppc: 0.791 +kernel: 0.767 +socket: 0.744 +boot: 0.738 +PID: 0.727 +i386: 0.659 + +[Cross compilation] qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Description of problem: +On the X86 platform, chroot to the latest MIP environment, download the source package, install the dependency, and then compile. It is found that the variation is in error + +Grab logs with GDB on the real machine + +Thread 1 "bash" received signal SIGSEGV, Segmentation fault. +0x00007f094429c656 in code_gen_buffer () +(gdb) bt +#0 0x00007f094429c656 in code_gen_buffer () +#1 0x000000000053878e in cpu_tb_exec (cpu=0x2441050, itb=<optimized out>, tb_exit=0x7ffd5bae38e8) at ../../accel/tcg/cpu-exec.c:353 +#2 0x000000000053965e in cpu_loop_exec_tb (tb_exit=0x7ffd5bae38e8, last_tb=<synthetic pointer>, tb=0x7f09441caac0 <code_gen_buffer+690835>, cpu=0x2441050) at ../../accel/tcg/cpu-exec.c:812 +#3 cpu_exec (cpu=cpu@entry=0x2441050) at ../../accel/tcg/cpu-exec.c:970 +#4 0x0000000000465b60 in cpu_loop (env=env@entry=0x2449340) at ../../linux-user/mips64/cpu_loop.c:78 +#5 0x0000000000413b27 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../linux-user/main.c:910 +(gdb) thread apply all bt + +Thread 2 (LWP 26312): +#0 0x0000000000766a19 in syscall () +#1 0x000000000058ee0a in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at ./include/qemu/trace-events:29 +#2 qemu_event_wait (ev=ev@entry=0xd44e68 <rcu_call_ready_event>) at ../../util/qemu-thread-posix.c:480 +#3 0x000000000059690a in call_rcu_thread (opaque=opaque@entry=0x0) at ./b/user-static/thread.h:258 +#4 0x000000000058dc29 in qemu_thread_start (args=<optimized out>) at ../../util/qemu-thread-posix.c:541 +#5 0x00000000006e665e in start_thread (arg=0x7f094c9a3640) at pthread_create.c:463 +#6 0x000000000076836f in clone () + +Thread 1 (LWP 26310): +#0 0x00007f094429c656 in code_gen_buffer () +#1 0x000000000053878e in cpu_tb_exec (cpu=0x2441050, itb=<optimized out>, tb_exit=0x7ffd5bae38e8) at ../../accel/tcg/cpu-exec.c:353 +#2 0x000000000053965e in cpu_loop_exec_tb (tb_exit=0x7ffd5bae38e8, last_tb=<synthetic pointer>, tb=0x7f09441caac0 <code_gen_buffer+690835>, cpu=0x2441050) at ../../accel/tcg/cpu-exec.c:812 +#3 cpu_exec (cpu=cpu@entry=0x2441050) at ../../accel/tcg/cpu-exec.c:970 +#4 0x0000000000465b60 in cpu_loop (env=env@entry=0x2449340) at ../../linux-user/mips64/cpu_loop.c:78 +#5 0x0000000000413b27 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../linux-user/main.c:910 +(gdb) +``` +Steps to reproduce: +``` +1.Minimum environment for building MIPS platform on +2.On X86 platform sudo chroot . +3.cd build +4.apt source adwaita-icon-theme +5.cd adwaita-icon-theme-3.30.1 +6.debuild -b +``` +Additional information: + diff --git a/results/classifier/118/graphic/761 b/results/classifier/118/graphic/761 new file mode 100644 index 000000000..3a5510261 --- /dev/null +++ b/results/classifier/118/graphic/761 @@ -0,0 +1,42 @@ +graphic: 0.976 +x86: 0.966 +KVM: 0.909 +device: 0.881 +vnc: 0.854 +performance: 0.846 +peripherals: 0.825 +permissions: 0.748 +kernel: 0.718 +PID: 0.650 +semantic: 0.644 +i386: 0.639 +mistranslation: 0.634 +register: 0.624 +architecture: 0.614 +boot: 0.537 +socket: 0.500 +risc-v: 0.463 +debug: 0.462 +files: 0.450 +VMM: 0.448 +arm: 0.404 +user-level: 0.384 +assembly: 0.322 +virtual: 0.285 +TCG: 0.248 +ppc: 0.235 +network: 0.224 +hypervisor: 0.191 + +With -display gtk,gl=on, the position of mouse does not show correctly +Description of problem: +With `-display gtk,gl=on`, the cursor of the mouse does not show correctly. So, it's very hard to use mouse on guest OS desktop to, say, open an application or to close it. The displayed mouse cursor is about 300x300 away from the actual mouse position. +Steps to reproduce: +1. Build qemu 6.2.0-rc2 using the following `./configure` options: +``` +--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-fuse --enable-fuse-lseek +``` +2. Run the above QEMU command with `-display gtk,gl=on`. +3. Try to open an application by clicking its icon on desktop and to close it by clicking the "X" icon. +Additional information: + diff --git a/results/classifier/118/graphic/768 b/results/classifier/118/graphic/768 new file mode 100644 index 000000000..28db62609 --- /dev/null +++ b/results/classifier/118/graphic/768 @@ -0,0 +1,42 @@ +graphic: 0.976 +virtual: 0.975 +x86: 0.966 +device: 0.944 +peripherals: 0.931 +KVM: 0.928 +vnc: 0.915 +VMM: 0.879 +performance: 0.826 +permissions: 0.790 +PID: 0.743 +debug: 0.717 +hypervisor: 0.712 +architecture: 0.702 +semantic: 0.641 +register: 0.620 +mistranslation: 0.620 +boot: 0.592 +network: 0.566 +i386: 0.538 +user-level: 0.527 +risc-v: 0.510 +files: 0.475 +kernel: 0.365 +assembly: 0.329 +socket: 0.322 +TCG: 0.287 +ppc: 0.267 +arm: 0.259 + +Mouse cursor disappears in RHEL guest when using "-device virtio-vga-gl -display gtk,gl=on" option +Description of problem: +Mouse cursor disappears in RHEL guest when using -device virtio-vga-gl -display gtk,gl=on +Steps to reproduce: +1. Build qemu using the following `./configure` options: +``` +--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-avx512f --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-gio --enable-fuse --enable-fuse-lseek +``` +2. Install Red Hat Enterprise Linux 8.5 in qemu +3. Run qemu using the above command line. The mouse cursor disappears once it moves into the VM. +Additional information: + diff --git a/results/classifier/118/graphic/769 b/results/classifier/118/graphic/769 new file mode 100644 index 000000000..57d1bf2ee --- /dev/null +++ b/results/classifier/118/graphic/769 @@ -0,0 +1,46 @@ +graphic: 0.920 +x86: 0.893 +KVM: 0.855 +vnc: 0.842 +device: 0.807 +boot: 0.798 +semantic: 0.757 +files: 0.687 +permissions: 0.682 +VMM: 0.648 +performance: 0.613 +kernel: 0.608 +register: 0.599 +socket: 0.591 +PID: 0.591 +risc-v: 0.578 +i386: 0.577 +architecture: 0.576 +hypervisor: 0.547 +TCG: 0.545 +ppc: 0.537 +virtual: 0.518 +network: 0.471 +peripherals: 0.429 +arm: 0.428 +assembly: 0.423 +user-level: 0.361 +debug: 0.351 +mistranslation: 0.345 + +When the VM is about to enter GUI desktop or quit the system, the screen turns upside down. +Description of problem: +When the VM is about to enter GUI desktop, the remaining booting message on the screen turns upside down. I was wondering if it is a designed feature or a bug. I like it because when I see it I'm ensured I'll enter the VM's GUI desktop soon without any problem. + +An edit: This happens also at the quitting time when I type "sudo shutdown now" in the terminal. +Steps to reproduce: +1. Build qemu using the following `./configure` options: +``` +--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-avx512f --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-gio --enable-fuse --enable-fuse-lseek +``` +2. Install Red Hat Enterprise Linux 8.5 in qemu +3. Run qemu using the above command line, or type "sudo shutdown now" in the terminal after VM starts. +Additional information: + + + diff --git a/results/classifier/118/graphic/771 b/results/classifier/118/graphic/771 new file mode 100644 index 000000000..f28a0fe28 --- /dev/null +++ b/results/classifier/118/graphic/771 @@ -0,0 +1,44 @@ +graphic: 0.833 +performance: 0.746 +boot: 0.742 +device: 0.709 +ppc: 0.426 +architecture: 0.416 +socket: 0.376 +user-level: 0.367 +semantic: 0.362 +peripherals: 0.360 +mistranslation: 0.342 +register: 0.338 +vnc: 0.319 +PID: 0.305 +debug: 0.278 +hypervisor: 0.265 +i386: 0.257 +risc-v: 0.254 +x86: 0.253 +kernel: 0.240 +assembly: 0.192 +arm: 0.165 +VMM: 0.160 +permissions: 0.144 +KVM: 0.131 +virtual: 0.103 +TCG: 0.101 +network: 0.064 +files: 0.063 + +No interrupts are delivered to the guest after rebooting Windows 98 +Description of problem: +After Windows 98 is rebooted in QEMU, the guest freezes: the system is unresponsive to key presses and the boot splash animation halts. The guest performs fine before the reboot. + +Closer examination reveals that no hardware interrupts are delivered to the guest. BIOS Data Area variables like the keyboard buffer and the system clock are not updated. Even non-maskable interrupts fail to be delivered, as witnessed by installing an option ROM that hooks interrupt vector 2 and issuing the `nmi` command in the monitor. + +The only remedy seems to be to exit the QEMU process entirely and launch it again. +Steps to reproduce: +0. Install Windows 98 into the guest. (Since the normal installation process already involves a couple of reboots, it is possible to hit the issue already at step zero.) +1. Boot it; it may be into Safe Mode, but the protected-mode graphical environment must at least attempt to load. (I managed sometimes to reproduce the bug without the system having loaded fully.) +2. Reboot. This may be a clean reboot, or it may be a hard reboot (`system_reset` or equivalent) +3. Observe the system freeze. +Additional information: +None diff --git a/results/classifier/118/graphic/786211 b/results/classifier/118/graphic/786211 new file mode 100644 index 000000000..5eb465411 --- /dev/null +++ b/results/classifier/118/graphic/786211 @@ -0,0 +1,38 @@ +graphic: 0.951 +semantic: 0.932 +ppc: 0.897 +architecture: 0.837 +device: 0.778 +socket: 0.728 +network: 0.666 +vnc: 0.616 +boot: 0.475 +risc-v: 0.460 +mistranslation: 0.444 +kernel: 0.408 +arm: 0.405 +VMM: 0.391 +assembly: 0.376 +i386: 0.358 +debug: 0.357 +PID: 0.336 +register: 0.334 +TCG: 0.329 +x86: 0.273 +files: 0.241 +performance: 0.199 +virtual: 0.191 +peripherals: 0.162 +KVM: 0.160 +permissions: 0.158 +user-level: 0.089 +hypervisor: 0.015 + +Missing checks for valid, writable, firmware in fw_cfg_write + +The `fw_cfg_write` function in the firmware emulation is missing checks to ensure that the firmware being written is (a) a valid index, and (b) writable. This can lead to a segmentation fault and potentially (in the case of writing to FW_CFG_INVALID), memory corruption, although the attacker has fairly limited control over whether and what corruption is possible. + + + +fw_cfg_write() support has been removed since QEMU 2.4, so I think we can treat this as fixed now: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=023e3148567ac898c725813 + diff --git a/results/classifier/118/graphic/788886 b/results/classifier/118/graphic/788886 new file mode 100644 index 000000000..613cc481a --- /dev/null +++ b/results/classifier/118/graphic/788886 @@ -0,0 +1,43 @@ +graphic: 0.851 +architecture: 0.836 +device: 0.725 +mistranslation: 0.669 +semantic: 0.519 +network: 0.514 +permissions: 0.450 +user-level: 0.448 +performance: 0.433 +vnc: 0.433 +debug: 0.338 +files: 0.311 +register: 0.301 +ppc: 0.298 +PID: 0.238 +boot: 0.232 +socket: 0.179 +arm: 0.158 +assembly: 0.151 +VMM: 0.136 +TCG: 0.122 +peripherals: 0.120 +kernel: 0.109 +hypervisor: 0.109 +virtual: 0.101 +x86: 0.087 +risc-v: 0.087 +i386: 0.063 +KVM: 0.015 + +Crash with -m32 and gcc-4.2 on Mac OS X 64bit + +For building 32bit Qemu on Mac OS X 10.6.7 , i configure with --extra-cflags=-m32 --extra-ldflags=-m32. make with gcc-4.2 then crashes with: + + GEN qemu-options.def + CC qemu-nbd.o +gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags +make: *** [qemu-nbd.o] Error 1 + +Which version of QEMU were you using? Can you still reproduce this problem with the latest version of QEMU and the latest version of macOS? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/789 b/results/classifier/118/graphic/789 new file mode 100644 index 000000000..3842f7d37 --- /dev/null +++ b/results/classifier/118/graphic/789 @@ -0,0 +1,42 @@ +graphic: 0.986 +user-level: 0.933 +arm: 0.932 +device: 0.902 +architecture: 0.755 +semantic: 0.702 +mistranslation: 0.587 +debug: 0.558 +PID: 0.490 +files: 0.424 +performance: 0.379 +boot: 0.267 +permissions: 0.228 +register: 0.214 +peripherals: 0.185 +virtual: 0.179 +vnc: 0.158 +ppc: 0.145 +network: 0.118 +TCG: 0.116 +hypervisor: 0.061 +VMM: 0.057 +i386: 0.051 +risc-v: 0.047 +socket: 0.042 +x86: 0.031 +assembly: 0.027 +kernel: 0.011 +KVM: 0.002 + +QEMU arm (not arm64) crashes on apple silicon when run via docker desktop +Description of problem: +docker build of the simple Dockerfile here causes QEMU to crash in arm +emulation. It is perfectly reproducible. + +FROM balenalib/rpi-raspbian:bullseye-20210925 + +USER root + +RUN apt-get update -y && apt-get upgrade -y +Additional information: + diff --git a/results/classifier/118/graphic/794 b/results/classifier/118/graphic/794 new file mode 100644 index 000000000..fd84a83ca --- /dev/null +++ b/results/classifier/118/graphic/794 @@ -0,0 +1,39 @@ +graphic: 0.900 +device: 0.819 +network: 0.803 +mistranslation: 0.656 +semantic: 0.632 +architecture: 0.628 +socket: 0.628 +vnc: 0.624 +debug: 0.617 +files: 0.605 +PID: 0.561 +register: 0.554 +TCG: 0.521 +arm: 0.518 +performance: 0.517 +risc-v: 0.490 +kernel: 0.489 +ppc: 0.473 +user-level: 0.468 +i386: 0.452 +boot: 0.445 +assembly: 0.427 +x86: 0.409 +VMM: 0.403 +hypervisor: 0.384 +KVM: 0.315 +peripherals: 0.315 +permissions: 0.238 +virtual: 0.233 + +Documentation: Broken links to removed features in old changelog pages +Description of problem: +In QEMU changelogs prior to 6.1 (notably 6.0 at least) the removed features link goes to https://qemu-project.gitlab.io/qemu/system/removed-features.html instead of https://qemu-project.gitlab.io/qemu/about/removed-features.html. The deprecated features links are also broken. + +This caused me some amount of confusion while trying to find the cause of several emulation issues. +Additional information: +Would have fixed myself but I cannot create a QEMU wiki account to do so. If there is a process for approval for that I will happily follow it and fix the issue when approved. I also can't see anywhere else to report this so apologies if this is the wrong place. + +Perhaps the main changelog page could include links to the removed and deprecated features pages too? diff --git a/results/classifier/118/graphic/813 b/results/classifier/118/graphic/813 new file mode 100644 index 000000000..bfa1ebfdf --- /dev/null +++ b/results/classifier/118/graphic/813 @@ -0,0 +1,45 @@ +graphic: 0.857 +device: 0.825 +virtual: 0.727 +architecture: 0.724 +performance: 0.718 +files: 0.672 +PID: 0.627 +arm: 0.548 +register: 0.515 +risc-v: 0.494 +semantic: 0.486 +permissions: 0.484 +vnc: 0.483 +boot: 0.467 +debug: 0.463 +peripherals: 0.453 +user-level: 0.448 +ppc: 0.447 +mistranslation: 0.410 +socket: 0.404 +kernel: 0.398 +TCG: 0.322 +VMM: 0.279 +network: 0.268 +assembly: 0.203 +i386: 0.201 +hypervisor: 0.186 +KVM: 0.164 +x86: 0.158 + +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/118/graphic/820 b/results/classifier/118/graphic/820 new file mode 100644 index 000000000..15cad7b25 --- /dev/null +++ b/results/classifier/118/graphic/820 @@ -0,0 +1,43 @@ +graphic: 0.940 +x86: 0.934 +device: 0.919 +architecture: 0.816 +boot: 0.754 +arm: 0.639 +semantic: 0.622 +files: 0.621 +virtual: 0.567 +performance: 0.515 +debug: 0.496 +mistranslation: 0.456 +user-level: 0.427 +hypervisor: 0.415 +i386: 0.378 +vnc: 0.366 +permissions: 0.274 +kernel: 0.264 +register: 0.258 +VMM: 0.226 +socket: 0.212 +ppc: 0.207 +KVM: 0.173 +PID: 0.166 +network: 0.161 +risc-v: 0.157 +TCG: 0.110 +peripherals: 0.087 +assembly: 0.078 + +Hang During Initramfs +Description of problem: +[Hang During Initramfs](https://wiki.archlinux.org/title/QEMU#Hang_during_VM_initramfs) +Is this still not fixed? I hang at startup. Previously I tried WIN11 and it booted fine. +Steps to reproduce: +1. Download Windows10 ISO +2. qemu-img create -f raw Windows10 15G +3. qemu-system-x86_64 -cdrom Win10.iso -boot order=d -drive file=Windows10,format=raw -m 4G +Additional information: + + + +`-enable-kvm` works but i removed it to slow down a bit to see what is going on. diff --git a/results/classifier/118/graphic/835 b/results/classifier/118/graphic/835 new file mode 100644 index 000000000..4ad9c4123 --- /dev/null +++ b/results/classifier/118/graphic/835 @@ -0,0 +1,39 @@ +graphic: 0.861 +device: 0.837 +debug: 0.644 +semantic: 0.603 +network: 0.575 +mistranslation: 0.533 +vnc: 0.515 +peripherals: 0.497 +arm: 0.493 +i386: 0.477 +performance: 0.474 +PID: 0.407 +boot: 0.397 +VMM: 0.395 +kernel: 0.392 +risc-v: 0.388 +x86: 0.388 +ppc: 0.384 +socket: 0.371 +KVM: 0.327 +TCG: 0.322 +architecture: 0.319 +register: 0.306 +permissions: 0.272 +user-level: 0.246 +files: 0.192 +hypervisor: 0.165 +virtual: 0.151 +assembly: 0.150 + +SDL display does not handle ps2 relative packets +Description of problem: +The main problem: while tracing relative events input_event_rel all mouse events are positive and seems to be the absolute x and y mouse position. When that happens ps2 sends a +x -y of a full 127 count. +Steps to reproduce: +1. Trace input_event_rel +2. Observe that when moving the mouse the trace always shows positive values, that doesn't depend on what direction you move the mouse +3. Observe that the xrel and yrel is more like absolute positions +Additional information: +I noticed searching on sdl2 docs and some issues related to SDL2 mouse events that when you do not specify SDL_HINT_MOUSE_RELATIVE_MODE_WARP weird things happens, i tried adding SDL_SetHint(SDL_HINT_MOUSE_RELATIVE_MODE_WARP, "1"); at the end of the sdl2 init function and the mouse events started to show normal values. I'm not sure if that's the correct way to solve the bug, but it seems to be. diff --git a/results/classifier/118/graphic/839 b/results/classifier/118/graphic/839 new file mode 100644 index 000000000..89ef7e9b9 --- /dev/null +++ b/results/classifier/118/graphic/839 @@ -0,0 +1,80 @@ +graphic: 0.808 +performance: 0.770 +risc-v: 0.768 +arm: 0.767 +network: 0.746 +device: 0.738 +virtual: 0.731 +peripherals: 0.724 +semantic: 0.724 +KVM: 0.721 +hypervisor: 0.712 +register: 0.709 +debug: 0.706 +permissions: 0.704 +TCG: 0.693 +socket: 0.688 +VMM: 0.677 +architecture: 0.675 +files: 0.667 +PID: 0.665 +ppc: 0.651 +assembly: 0.642 +user-level: 0.636 +kernel: 0.625 +vnc: 0.615 +boot: 0.601 +x86: 0.599 +i386: 0.492 +mistranslation: 0.333 + +qxl in COLO secondary node cause QEMU to segmentation fault +Description of problem: +After COLO checkpoint, the Secondary VM's qemu received segmentation fault while releasing qxl resources in interface_release_resource() routine. +i have used gdb and qemu trace to debug Secondary VM's qemu. the object 'qxl->last_release' is null and object 'ring->items[prod].el' != 0, it leads to null pointer dereference. +During COLO checkpoint,the Secondary VM's qemu has loaded Primary VM's qxl states,so i think it not need to release qxl resources. +Steps to reproduce: +1.Startup Primary VM and Secondary VM of COLO mode, and gdb to Secondary VM's qemu. +2.Connect to Primary VM's spice server. +3.Secondary VM's qemu will receiveing segmentation fault. +Additional information: +gdb to Secondary VM's qemu: + ``` +Program received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7ff9e3bff700 (LWP 44703)] +0x0000555555b2e8d6 in interface_release_resource (sin=0x555557d7c8a8, ext=...) at ../hw/display/qxl.c:783 +783 qxl->last_release->next = ext.info->id; +(gdb) bt +#0 0x0000555555b2e8d6 in interface_release_resource (sin=0x555557d7c8a8, ext=...) at ../hw/display/qxl.c:783 +#1 0x00007fffd7751dd1 in red_drawable_unref () at /lib64/libspice-server.so.1 +#2 0x00007fffd771eabe in drawable_unref () at /lib64/libspice-server.so.1 +#3 0x00007fffd77206a7 in draw_until () at /lib64/libspice-server.so.1 +#4 0x00007fffd771f7cd in display_channel_draw () at /lib64/libspice-server.so.1 +#5 0x00007fffd7721b51 in display_channel_process_draw () at /lib64/libspice-server.so.1 +#6 0x00007fffd7752142 in red_process_display () at /lib64/libspice-server.so.1 +#7 0x00007fffd77521fb in worker_source_dispatch () at /lib64/libspice-server.so.1 +#8 0x00007fffd6c2f049 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 +#9 0x00007fffd6c2f3a8 in g_main_context_iterate.isra.19 () at /lib64/libglib-2.0.so.0 +#10 0x00007fffd6c2f67a in g_main_loop_run () at /lib64/libglib-2.0.so.0 +#11 0x00007fffd775166a in red_worker_main () at /lib64/libspice-server.so.1 +#12 0x00007fffd5658dd5 in start_thread () at /lib64/libpthread.so.0 +#13 0x00007fffd538202d in clone () at /lib64/libc.so.6 +(gdb) frame 0 +#0 0x0000555555b2e8d6 in interface_release_resource (sin=0x555557d7c8a8, ext=...) at ../hw/display/qxl.c:783 +783 qxl->last_release->next = ext.info->id; +(gdb) print qxl->last_release +$1 = (QXLReleaseInfo *) 0x0 + ``` + +qemu trace log: + ``` +44840@1643012769.363844:colo_send_message Send 'checkpoint-reply' message +44840@1643012773.579053:colo_receive_message Receive 'vmstate-send' message +44840@1643012773.978838:colo_receive_message Receive 'vmstate-size' message +44840@1643012773.979041:colo_send_message Send 'vmstate-received' message +44840@1643012774.180598:qxl_pre_load 0 +44703@1643012774.180660:qxl_ring_res_put 0 #res=20 +44840@1643012774.182627:qxl_post_load 0 native +44840@1643012774.197993:colo_vm_state_change Change 'stop' => 'run' +44840@1643012774.198030:colo_send_message Send 'vmstate-loaded' message + ``` diff --git a/results/classifier/118/graphic/855 b/results/classifier/118/graphic/855 new file mode 100644 index 000000000..560d3652b --- /dev/null +++ b/results/classifier/118/graphic/855 @@ -0,0 +1,47 @@ +graphic: 0.984 +kernel: 0.959 +boot: 0.908 +architecture: 0.908 +device: 0.858 +vnc: 0.856 +PID: 0.851 +files: 0.812 +VMM: 0.805 +performance: 0.797 +register: 0.767 +semantic: 0.733 +ppc: 0.728 +virtual: 0.712 +permissions: 0.703 +socket: 0.675 +risc-v: 0.663 +debug: 0.631 +network: 0.603 +x86: 0.598 +user-level: 0.578 +TCG: 0.517 +arm: 0.489 +peripherals: 0.404 +mistranslation: 0.364 +KVM: 0.304 +hypervisor: 0.270 +i386: 0.219 +assembly: 0.158 + +Prebuilt seabios vgabios-stdvga binary causes onboot kernel panics for freebsd 10.0 +Description of problem: +FreeBSD 10.0 panics on boot since commit: `0221d73ce6a8e075adaa0a35a6ef853d2652b855`, see my attached screenshot of the panic. +I digged a bit into what specifically causes the issue, it seems to be caused by the precompiled `vgabios-stdvga.bin`. +I don't see this issue come up when I compile the binary myself via the `roms/` folder with different versions of gcc via gcc docker containers. +But once I compile the `vgabios-stdvga` from the `roms/` folder with a more modern Ubuntu version (21.10) using gcc 11.2, I also get panics on my `vgabios-stdvga`. +At first I thought it was caused by a different gcc version, but since the buster gcc docker container images create correctly functioning `vgabios-stdvga.bin` binaries, I think this is caused by a newer version of the linker coming from the `binutils` package. + +My local Ubuntu version has version 2.37 of the binutils package, the `gcc:11.2` container which compiles a correct `vgabios-stdvga.bin` has version `2.35.2` of the binutils package. + + +Steps to reproduce: +1. Compile any version after the mentioned commit using the precompiled seabios binaries +2. Try to boot freebsd 10.0-RELEASE +3. Kernel panic because of a page vault during the vesa module load. +Additional information: +https://mfsbsd.vx.sk/files/iso/10/amd64/mfsbsd-10.0-RELEASE-amd64.iso diff --git a/results/classifier/118/graphic/857 b/results/classifier/118/graphic/857 new file mode 100644 index 000000000..436f01d84 --- /dev/null +++ b/results/classifier/118/graphic/857 @@ -0,0 +1,42 @@ +x86: 0.989 +architecture: 0.967 +graphic: 0.931 +device: 0.872 +files: 0.856 +semantic: 0.828 +debug: 0.803 +network: 0.735 +performance: 0.706 +mistranslation: 0.675 +socket: 0.669 +PID: 0.652 +register: 0.599 +permissions: 0.599 +vnc: 0.562 +peripherals: 0.508 +user-level: 0.490 +ppc: 0.465 +arm: 0.411 +risc-v: 0.361 +boot: 0.350 +TCG: 0.307 +VMM: 0.290 +kernel: 0.226 +virtual: 0.170 +i386: 0.133 +hypervisor: 0.120 +assembly: 0.106 +KVM: 0.084 + +qemu-x86_64 uses host libraries instead of emulated system libraries +Description of problem: +I'm using Buildroot to build a cross-compiled embedded Linux system. During the build process there is a little hack to create some header file using a cross-compiled application. For this hack they use qemu to run this application. Building this embedded system for aarch64 work fine, but for x86_64 I get the following messages: + +bytecode_builtins_list_generator: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by bytecode_builtins_list_generator) +bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by bytecode_builtins_list_generator) +bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by bytecode_builtins_list_generator) +bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by bytecode_builtins_list_generator) + +The path of the libraries in this error message is from my host system. The embedded system uses /lib64 or /usr/lib64. It seems to me that the linker search for the libraries at first on the host system and later uses the path from the command line. So you have a mixed up of host and embedded system libraries (as you can see in the attached strace log). +Additional information: +[qemu-1.log](/uploads/f53e98b6b15cce7cbf94d14dffa39f90/qemu-1.log) diff --git a/results/classifier/118/graphic/860 b/results/classifier/118/graphic/860 new file mode 100644 index 000000000..9189b0883 --- /dev/null +++ b/results/classifier/118/graphic/860 @@ -0,0 +1,340 @@ +graphic: 0.866 +arm: 0.803 +register: 0.767 +ppc: 0.750 +virtual: 0.745 +peripherals: 0.740 +device: 0.738 +semantic: 0.738 +permissions: 0.734 +assembly: 0.721 +PID: 0.713 +KVM: 0.704 +hypervisor: 0.700 +TCG: 0.680 +architecture: 0.671 +performance: 0.660 +network: 0.651 +vnc: 0.643 +debug: 0.630 +risc-v: 0.619 +VMM: 0.616 +boot: 0.603 +kernel: 0.595 +user-level: 0.586 +mistranslation: 0.577 +socket: 0.566 +files: 0.539 +x86: 0.370 +i386: 0.264 + +Not able to launch guests in ppc64le P9 OPAL +Description of problem: +Not able to launch guests in ppc64le P9 OPAL +Steps to reproduce: +1. In a RHEL8 using 4.18.0-305.3.1.el8_4.ppc64le create a Fedora CoreOS VM using kernel-5.15.17-200.fc35.ppc64le. +2. Inside the FCOS vm run: +``` +virt-install --import \ + --name buildvm-ppc64le-fcos01.iad2.fedoraproject.org \ + --memory=32768,maxmemory=32768 \ + --vcpus=16,maxvcpus=16 \ + --feature nested-hv=on \ + --network bridge=br0,model=virtio,mac=RANDOM \ + --autostart \ + --memballoon virtio \ + --watchdog default \ + --rng /dev/random \ + --noautoconsole \ + --disk path=$PWD/fcos-ppc64le-builder.ign,format=raw,readonly=on,serial=ignition \ + --disk bus=virtio,path=/dev/vg_guests/buildvm-ppc64le-fcos01.iad2.fedoraproject.org,cache=unsafe,io=threads +``` + +3. Try to run it again and you will get: + +``` +KVM: Failed to create TCE64 table for liobn 0x71000002 +KVM: Failed to create TCE64 table for liobn 0x80000000 +KVM: unknown exit, hardware reason ffffffffffffffc9 +NIP 0000000000000100 LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 CPU#0 +MSR 8000000000001000 HID0 0000000000000000 HF 6c000004 iidx 3 didx 3 +TB 00000000 00000000 DECR 0 +GPR00 0000000000000000 0000000000000000 0000000000000000 000000007fe00000 +GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +CR 00000000 [ - - - - - - - - ] RES ffffffffffffffff + SRR0 0000000000000000 SRR1 0000000000000000 PVR 00000000004e1202 VRSAVE 0000000000000000 +SPRG0 0000000000000000 SPRG1 0000000000000000 SPRG2 0000000000000000 SPRG3 0000000000000000 +SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 0000000000000000 +HSRR0 0000000000000000 HSRR1 0000000000000000 + CFAR 0000000000000000 + LPCR 0000000000560413 + PTCR 0000000000000000 DAR 0000000000000000 DSISR 0000000000000000 +``` +Additional information: +Fedora xml: +``` +<domain type='kvm' id='24'> + <name>buildvm-ppc64le-fcos01.iad2.fedoraproject.org</name> + <uuid>ed30c95e-b7c0-4c25-a6ba-b739459f101b</uuid> + <memory unit='KiB'>33554432</memory> + <currentMemory unit='KiB'>33554432</currentMemory> + <vcpu placement='static'>16</vcpu> + <resource> + <partition>/machine</partition> + </resource> + <os> + <type arch='ppc64le' machine='pseries-rhel8.3.0'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <nested-hv state='on'/> + </features> + <cpu mode='custom' match='exact' check='none'> + <model fallback='forbid'>POWER9</model> + </cpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/libexec/qemu-kvm</emulator> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='unsafe' io='threads'/> + <source dev='/dev/vg_guests/buildvm-ppc64le-fcos01.iad2.fedoraproject.org' index='2'/> + <backingStore/> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='raw'/> + <source file='/tmp/fcos-ppc64le-builder.ign' index='1'/> + <backingStore/> + <target dev='vdb' bus='virtio'/> + <readonly/> + <serial>ignition</serial> + <alias name='virtio-disk1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </disk> + <controller type='usb' index='0' model='qemu-xhci' ports='15'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <model name='spapr-pci-host-bridge'/> + <target index='0'/> + <alias name='pci.0'/> + </controller> + <controller type='virtio-serial' index='0'> + <alias name='virtio-serial0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:c4:d2:aa'/> + <source bridge='br0'/> + <target dev='vnet23'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/11'/> + <target type='spapr-vio-serial' port='0'> + <model name='spapr-vty'/> + </target> + <alias name='serial0'/> + <address type='spapr-vio' reg='0x30000000'/> + </serial> + <console type='pty' tty='/dev/pts/11'> + <source path='/dev/pts/11'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + <address type='spapr-vio' reg='0x30000000'/> + </console> + <channel type='unix'> + <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-24-buildvm-ppc64le-fcos/org.qemu.guest_agent.0'/> + <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> + <alias name='channel0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='tablet' bus='usb'> + <alias name='input0'/> + <address type='usb' bus='0' port='1'/> + </input> + <input type='keyboard' bus='usb'> + <alias name='input1'/> + <address type='usb' bus='0' port='2'/> + </input> + <graphics type='vnc' port='5910' autoport='yes' listen='127.0.0.1'> + <listen type='address' address='127.0.0.1'/> + </graphics> + <video> + <model type='vga' vram='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </video> + <watchdog model='i6300esb' action='reset'> + <alias name='watchdog0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </watchdog> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </memballoon> + <rng model='virtio'> + <backend model='random'>/dev/random</backend> + <alias name='rng0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </rng> + <panic model='pseries'/> + </devices> + <seclabel type='dynamic' model='selinux' relabel='yes'> + <label>system_u:system_r:svirt_t:s0:c131,c913</label> + <imagelabel>system_u:object_r:svirt_image_t:s0:c131,c913</imagelabel> + </seclabel> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+107:+107</label> + <imagelabel>+107:+107</imagelabel> + </seclabel> +</domain> +``` + +Failure seen in journal when running `virt-ls` + +``` +Feb 04 16:19:39 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: KVMPPC-UVMEM: No support for secure guests +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: vcpu 000000004bd9d345 (0): +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: pc = 0000000000000100 msr = 8000000000001000 trap = ffffffc9 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 0 = 0000000000000000 r16 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 1 = 0000000000000000 r17 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 2 = 0000000000000000 r18 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 3 = 000000003fe00000 r19 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 4 = 0000000000000000 r20 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 5 = 0000000000000000 r21 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 6 = 0000000000000000 r22 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 7 = 0000000000000000 r23 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 8 = 0000000000000000 r24 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r 9 = 0000000000000000 r25 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r10 = 0000000000000000 r26 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r11 = 0000000000000000 r27 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r12 = 0000000000000000 r28 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r13 = 0000000000000000 r29 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r14 = 0000000000000000 r30 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: r15 = 0000000000000000 r31 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: ctr = 0000000000000000 lr = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: srr0 = 0000000000000000 srr1 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: sprg0 = 0000000000000000 sprg1 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: sprg2 = 0000000000000000 sprg3 = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: cr = 00000000 xer = 0000000000000000 dsisr = 00000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: dar = 0000000000000000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: fault dar = 0000000000000000 dsisr = 0c68f000 +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: SLB (0 entries): +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: lpcr = 0040000000560413 sdr1 = 0000000000000000 last_inst = ffffffff +Feb 04 16:19:40 buildvm-ppc64le-fcos01.iad2.fedoraproject.org kernel: trap=0xffffffc9 | pc=0x100 | msr=0x8000000000001000 +``` +Running via qemu: +``` +qemu-system-ppc64 -m 2048 -machine pseries,accel=kvm,kvm-type=HV -cpu host -nographic -snapshot -drive if=virtio,file=fedora-coreos-35.20220131.dev.0-qemu.ppc64le.qcow2 + +KVM: unknown exit, hardware reason ffffffffffffffc9 +NIP 0000000000000100 LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 CPU#0 +MSR 8000000000001000 HID0 0000000000000000 HF 6c000004 iidx 3 didx 3 +TB 00000000 00000000 DECR 0 +GPR00 0000000000000000 0000000000000000 0000000000000000 000000007fe00000 +GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +CR 00000000 [ - - - - - - - - ] RES ffffffffffffffff + SRR0 0000000000000000 SRR1 0000000000000000 PVR 00000000004e1202 VRSAVE 0000000000000000 +SPRG0 0000000000000000 SPRG1 0000000000000000 SPRG2 0000000000000000 SPRG3 0000000000000000 +SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 0000000000000000 +HSRR0 0000000000000000 HSRR1 0000000000000000 + CFAR 0000000000000000 + LPCR 0000000000560413 + PTCR 0000000000000000 DAR 0000000000000000 DSISR 0000000000000000 +``` +libguestfs-test-tool also fails to launch guest + +``` +2022-02-04 18:10:02.355+0000: starting up libvirt version: 7.6.0, package: 5.fc35 (Fedora Project, 2021-12-16-17:58:25, ), qemu version: 6.1.0qemu-6.1.0-10.fc35, kernel: 5.15.17-200.fc35.ppc64le, hostname: buildvm-ppc64le-fcos01.iad2.fedoraproject.org +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-1-guestfs-9ee177vxogzf \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-1-guestfs-9ee177vxogzf/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-1-guestfs-9ee177vxogzf/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-1-guestfs-9ee177vxogzf/.config \ +TMPDIR=/var/tmp \ +/usr/bin/qemu-system-ppc64 \ +-name guest=guestfs-9ee177vxogzfyj3v,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-1-guestfs-9ee177vxogzf/master-key.aes"}' \ +-machine pseries-6.1,accel=kvm,usb=off,dump-guest-core=off,memory-backend=ppc_spapr.ram \ +-cpu POWER9 \ +-m 1280 \ +-object '{"qom-type":"memory-backend-ram","id":"ppc_spapr.ram","size":1342177280}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid 08cd47d3-91e1-4322-aa53-6665a9bc13c8 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=22,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc,driftfix=slew \ +-no-reboot \ +-boot strict=on \ +-kernel /var/tmp/.guestfs-0/appliance.d/kernel \ +-initrd /var/tmp/.guestfs-0/appliance.d/initrd \ +-append 'panic=1 console=hvc0 console=ttyS0 edd=off udevtimeout=6000 udev.event-timeout=6000 no_timer_check printk.time=1 cgroup_disable=memory usbcore.nousb cryptomgr.notests tsc=reliable 8250.nr_uarts=1 root=UUID=0c185770-d5fc-4a67-acc9-3ea85178bda2 selinux=0 guestfs_verbose=1 TERM=screen' \ +-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x1 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x2 \ +-blockdev '{"driver":"file","filename":"/tmp/libguestfskYy342/scratch1.img","node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":true},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":false,"no-flush":true},"driver":"raw","file":"libvirt-2-storage"}' \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=libvirt-2-format,id=scsi0-0-0-0,bootindex=1,write-cache=on \ +-blockdev '{"driver":"file","filename":"/var/tmp/.guestfs-0/appliance.d/root","node-name":"libvirt-3-storage","cache":{"direct":false,"no-flush":true},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":true,"cache":{"direct":false,"no-flush":true},"driver":"raw","file":"libvirt-3-storage"}' \ +-blockdev '{"driver":"file","filename":"/tmp/libguestfskYy342/overlay2.qcow2","node-name":"libvirt-1-storage","cache":{"direct":false,"no-flush":true},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":false,"no-flush":true},"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-3-format"}' \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,device_id=drive-scsi0-0-1-0,drive=libvirt-1-format,id=scsi0-0-1-0,write-cache=on \ +-chardev socket,id=charserial0,path=/tmp/libguestfsFFWbf9/console.sock \ +-device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 \ +-chardev socket,id=charchannel0,path=/tmp/libguestfsFFWbf9/guestfsd.sock \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 \ +-audiodev id=audio1,driver=none \ +-object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \ +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x3 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +KVM: unknown exit, hardware reason ffffffffffffffc9 +NIP 0000000000000100 LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 CPU#0 +MSR 8000000000001000 HID0 0000000000000000 HF 6c000004 iidx 3 didx 3 +TB 00000000 00000000 DECR 0 +GPR00 0000000000000000 0000000000000000 0000000000000000 000000003fe00000 +GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +CR 00000000 [ - - - - - - - - ] RES ffffffffffffffff + SRR0 0000000000000000 SRR1 0000000000000000 PVR 00000000004e1202 VRSAVE 0000000000000000 +SPRG0 0000000000000000 SPRG1 0000000000000000 SPRG2 0000000000000000 SPRG3 0000000000000000 +SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 0000000000000000 +HSRR0 0000000000000000 HSRR1 0000000000000000 + CFAR 0000000000000000 + LPCR 0000000000560413 + PTCR 0000000000000000 DAR 0000000000000000 DSISR 0000000000000000 +2022-02-04T18:19:47.323915Z qemu-system-ppc64: terminating on signal 15 from pid 1645 (<unknown process>) +2022-02-04 18:19:47.524+0000: shutting down, reason=destroyed +``` diff --git a/results/classifier/118/graphic/867 b/results/classifier/118/graphic/867 new file mode 100644 index 000000000..00d350ba1 --- /dev/null +++ b/results/classifier/118/graphic/867 @@ -0,0 +1,43 @@ +graphic: 0.879 +device: 0.811 +x86: 0.742 +semantic: 0.535 +network: 0.496 +socket: 0.494 +mistranslation: 0.460 +kernel: 0.428 +performance: 0.384 +user-level: 0.336 +architecture: 0.319 +vnc: 0.316 +risc-v: 0.315 +debug: 0.297 +KVM: 0.268 +files: 0.268 +PID: 0.263 +peripherals: 0.239 +permissions: 0.233 +VMM: 0.199 +ppc: 0.178 +hypervisor: 0.171 +register: 0.155 +boot: 0.118 +virtual: 0.110 +arm: 0.084 +TCG: 0.075 +i386: 0.056 +assembly: 0.048 + +qemu-system-x86_64: warning: usb-redir connection broken during migration +Description of problem: +Create Snapshot, Restore snapshot, crash +Steps to reproduce: +1. Create Snapshot +2. Restore Snapshot +3. Crash +Additional information: + + +No redirecting: + + diff --git a/results/classifier/118/graphic/868 b/results/classifier/118/graphic/868 new file mode 100644 index 000000000..f705a1952 --- /dev/null +++ b/results/classifier/118/graphic/868 @@ -0,0 +1,45 @@ +graphic: 0.983 +device: 0.815 +semantic: 0.691 +register: 0.610 +user-level: 0.579 +performance: 0.546 +virtual: 0.504 +risc-v: 0.459 +mistranslation: 0.416 +PID: 0.383 +TCG: 0.369 +boot: 0.368 +arm: 0.366 +permissions: 0.342 +debug: 0.341 +vnc: 0.330 +ppc: 0.330 +VMM: 0.284 +assembly: 0.263 +architecture: 0.247 +files: 0.226 +socket: 0.213 +KVM: 0.184 +network: 0.182 +i386: 0.145 +x86: 0.130 +kernel: 0.100 +hypervisor: 0.070 +peripherals: 0.046 + +Graphic session freezes and logs out +Description of problem: +Graphic session freezes and logs out resetting user session. I've tried with both X and Wayland. +The session does not last longer than 10-15 mins while working with: + VSCode + Firefox browser (no more than 5 open tabs - nothing heavy) + +If only using console, the problem does not seem occur, or maybe it takes longer, but haven't been able to reproduce it. +Steps to reproduce: +No steps. Just using common apps (vscode editor and ffox browser) for 10-15 mins causes the problem. Standard sites: gitlab, stacoverflow. +Additional information: +I used this configuration for +1 year without issues. I guess some updates to either Ubuntu or Lubuntu causes the problem. +I deleted the guest VM and started with a fresh new Lubuntu 20.04 LTS AS IS no exttra software and the problem persists. + +Happy to provide any info you may require. I've looked around in the logs but couldnn't find anything useful. diff --git a/results/classifier/118/graphic/869 b/results/classifier/118/graphic/869 new file mode 100644 index 000000000..cbcb1f1e0 --- /dev/null +++ b/results/classifier/118/graphic/869 @@ -0,0 +1,51 @@ +graphic: 0.827 +device: 0.792 +files: 0.650 +semantic: 0.623 +architecture: 0.600 +performance: 0.583 +arm: 0.523 +network: 0.427 +mistranslation: 0.418 +boot: 0.415 +PID: 0.401 +debug: 0.391 +socket: 0.353 +peripherals: 0.342 +permissions: 0.340 +user-level: 0.324 +register: 0.320 +virtual: 0.272 +ppc: 0.250 +vnc: 0.249 +i386: 0.230 +x86: 0.208 +hypervisor: 0.170 +kernel: 0.137 +risc-v: 0.112 +TCG: 0.106 +assembly: 0.101 +VMM: 0.073 +KVM: 0.008 + +Qemu-system-avr working example +Description of problem: +I'm trying to get an Arduino board emulated with QEMU. Unfortunately, I can't get it to work. +I tried the commands, given in [https://qemu.readthedocs.io/en/latest/system/target-avr.html](https://qemu.readthedocs.io/en/latest/system/target-avr.html) and also downloaded and used the example elf file. + + +I then tried some more basic commands and used`qemu-system-avr -machine uno`. This should +run without any problems or? I also tried `2009` and `mega2560`. + +I also searched on the internet about working examples as well as further usage information, but I couldn't really find much. +Therefore, I hope someone can help me out or point me to additional material. +Steps to reproduce: +1. run `qemu-system-avr -machine uno` +2. wait around 5-10 seconds +3. on the terminal the following message appears with the qemu window crashing +``` +$ qemu-system-avr -machine uno + qemu-system-avr: execution left flash memory +``` +Additional information: +I'm fairly new to this, so please excuse me if I forgot something to post or made a mistake while posting. diff --git a/results/classifier/118/graphic/871 b/results/classifier/118/graphic/871 new file mode 100644 index 000000000..1e5feb1d9 --- /dev/null +++ b/results/classifier/118/graphic/871 @@ -0,0 +1,44 @@ +graphic: 0.875 +x86: 0.722 +device: 0.688 +architecture: 0.409 +performance: 0.327 +network: 0.265 +semantic: 0.249 +debug: 0.216 +PID: 0.186 +kernel: 0.179 +user-level: 0.162 +mistranslation: 0.157 +hypervisor: 0.156 +VMM: 0.088 +boot: 0.080 +ppc: 0.075 +socket: 0.064 +arm: 0.063 +files: 0.058 +TCG: 0.054 +vnc: 0.049 +i386: 0.048 +permissions: 0.043 +virtual: 0.039 +risc-v: 0.038 +register: 0.037 +peripherals: 0.034 +assembly: 0.030 +KVM: 0.012 + +qemu-x86_64 don't support unshare(CLONE_NEWUSER) +Description of problem: +Why qemu-x86_64 call unshare(CLONE_NEWUSER) fail? +``` + fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ qemu-x86_64 /bin/unshare --user /bin/bash + unshare: unshare failed: Invalid argument + fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ /bin/unshare --user /bin/bash + nobody@ubuntu:~/Desktop/afl/AFLplusplus$ +``` +Steps to reproduce: +1.execute `qemu-x86_64 /bin/unshare --user /bin/bash` ,it will fail <br/> +2.execute `/bin/unshare --user /bin/bash` ,it will ok + +How i fix that? diff --git a/results/classifier/118/graphic/877 b/results/classifier/118/graphic/877 new file mode 100644 index 000000000..c3b2dba78 --- /dev/null +++ b/results/classifier/118/graphic/877 @@ -0,0 +1,136 @@ +graphic: 0.915 +permissions: 0.893 +ppc: 0.891 +semantic: 0.872 +arm: 0.861 +PID: 0.857 +user-level: 0.854 +peripherals: 0.845 +performance: 0.845 +debug: 0.842 +register: 0.841 +assembly: 0.840 +x86: 0.831 +device: 0.812 +boot: 0.806 +files: 0.802 +hypervisor: 0.796 +TCG: 0.794 +architecture: 0.791 +kernel: 0.785 +virtual: 0.756 +risc-v: 0.750 +mistranslation: 0.745 +socket: 0.726 +network: 0.722 +VMM: 0.715 +vnc: 0.712 +KVM: 0.686 +i386: 0.511 + +qemu-system-x86_64: Linux kernel warning when CONFIG_NUMA_EMU is enabled +Description of problem: +When Linux kernel is run on qemu 6.2, it prints a warning when `NUMA_EMU` is used. When the same kernel is run on qemu 6.1.1 (`54e1f5be86dd11744e45da8be6afad01d01d59e7`) or earlier, no such warning is printed. + +``` +[ 0.341924] smpboot: CPU0: Intel QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1) +[ 0.342371] Performance Events: unsupported Netburst CPU model 107 no PMU driver, software events only. +[ 0.343302] rcu: Hierarchical SRCU implementation. +[ 0.344470] smp: Bringing up secondary CPUs ... +[ 0.345349] x86: Booting SMP configuration: +[ 0.345945] .... node #1, CPUs: #1 +[ 0.014099] ------------[ cut here ]------------ +[ 0.014099] sched: CPU #1's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency. +[ 0.014099] WARNING: CPU: 1 PID: 0 at arch/x86/kernel/smpboot.c:423 topology_sane.isra.0+0x62/0x70 +[ 0.014099] Modules linked in: +[ 0.014099] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.16.9 #6 +[ 0.014099] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 +[ 0.014099] RIP: 0010:topology_sane.isra.0+0x62/0x70 +[ 0.014099] Code: 80 3d e1 72 a1 01 00 75 f6 48 83 ec 08 4c 89 da 44 89 d6 48 c7 c7 c0 cd f4 8b 88 44 24 07 c6 05 c3 72 a1 01 01 e8 3c 16 b7 00 <0f> 0b 0f b6 44 24 07 48 83 c4 08 c3 66 90 48 8b 0d 21 95 a3 01 0f +[ 0.014099] RSP: 0000:ffffa8c3006a3ed8 EFLAGS: 00010086 +[ 0.014099] RAX: 0000000000000000 RBX: ffffa335fdc15480 RCX: 0000000000000000 +[ 0.014099] RDX: 0000000000000002 RSI: 00000000ffffffea RDI: 00000000ffffffff +[ 0.014099] RBP: ffffa3353dc15480 R08: ffffffff8c335ac8 R09: 00000000ffffdfff +[ 0.014099] R10: ffffffff8c255ae0 R11: ffffffff8c255ae0 R12: 0000000000000001 +[ 0.014099] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 +[ 0.014099] FS: 0000000000000000(0000) GS:ffffa335fdc00000(0000) knlGS:0000000000000000 +[ 0.014099] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 0.014099] CR2: 0000000000000000 CR3: 0000000112a0c000 CR4: 00000000000006e0 +[ 0.014099] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 0.014099] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 0.014099] Call Trace: +[ 0.014099] <TASK> +[ 0.014099] set_cpu_sibling_map+0x16a/0x560 +[ 0.014099] start_secondary+0x42/0xf0 +[ 0.014099] secondary_startup_64_no_verify+0xc2/0xcb +[ 0.014099] </TASK> +[ 0.014099] Kernel panic - not syncing: panic_on_warn set ... +[ 0.014099] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.16.9 #6 +[ 0.014099] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 +[ 0.014099] Call Trace: +[ 0.014099] <TASK> +[ 0.014099] dump_stack_lvl+0x34/0x44 +[ 0.014099] panic+0xef/0x2a6 +[ 0.014099] ? topology_sane.isra.0+0x62/0x70 +[ 0.014099] __warn.cold+0x26/0x30 +[ 0.014099] ? topology_sane.isra.0+0x62/0x70 +[ 0.014099] report_bug+0x9a/0xc0 +[ 0.014099] handle_bug+0x3c/0x60 +[ 0.014099] exc_invalid_op+0x14/0x70 +[ 0.014099] asm_exc_invalid_op+0x12/0x20 +[ 0.014099] RIP: 0010:topology_sane.isra.0+0x62/0x70 +[ 0.014099] Code: 80 3d e1 72 a1 01 00 75 f6 48 83 ec 08 4c 89 da 44 89 d6 48 c7 c7 c0 cd f4 8b 88 44 24 07 c6 05 c3 72 a1 01 01 e8 3c 16 b7 00 <0f> 0b 0f b6 44 24 07 48 83 c4 08 c3 66 90 48 8b 0d 21 95 a3 01 0f +[ 0.014099] RSP: 0000:ffffa8c3006a3ed8 EFLAGS: 00010086 +[ 0.014099] RAX: 0000000000000000 RBX: ffffa335fdc15480 RCX: 0000000000000000 +[ 0.014099] RDX: 0000000000000002 RSI: 00000000ffffffea RDI: 00000000ffffffff +[ 0.014099] RBP: ffffa3353dc15480 R08: ffffffff8c335ac8 R09: 00000000ffffdfff +[ 0.014099] R10: ffffffff8c255ae0 R11: ffffffff8c255ae0 R12: 0000000000000001 +[ 0.014099] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 +[ 0.014099] ? topology_sane.isra.0+0x62/0x70 +[ 0.014099] set_cpu_sibling_map+0x16a/0x560 +[ 0.014099] start_secondary+0x42/0xf0 +[ 0.014099] secondary_startup_64_no_verify+0xc2/0xcb +[ 0.014099] </TASK> +[ 0.014099] ---[ end Kernel panic - not syncing: panic_on_warn set ... ]--- +``` +Steps to reproduce: +1. Check out the Linux kernel: +``` +git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git +cd linux-stable +git checkout v5.16.9 +``` +2. Generate the configuration file: +``` +make defconfig +./scripts/config -e NUMA_EMU -e CMDLINE_BOOL --set-str CMDLINE "numa=fake=2 panic_on_warn=1" -d CONFIG_CMDLINE_OVERRIDE +``` +3. Build the kernel +``` +make -j32 +``` +4. Run qemu and wait for a couple of seconds: +``` +./qemu-system-x86_64 -m 4G -smp 2 -kernel ~/linux-stable/arch/x86/boot/bzImage -append "console=ttyS0 root=/dev/sda earlyprintk=serial" -enable-kvm -nographic -snapshot +``` +Additional information: +With explicit NUMA configuration, it boots fine: +``` +./qemu-system-x86_64 -m 4G -smp 2 -object memory-backend-ram,size=8G,id=m0 -numa node,cpus=0-1,nodeid=0,memdev=m0 -kernel ~/linux-stable/arch/x86/boot/bzImage -append "console=ttyS0 root=/dev/sda earlyprintk=serial" -enable-kvm -nographic -snapshot +``` + +On the host machine: +``` +$ 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 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 +node 0 size: 95259 MB +node 0 free: 1767 MB +node 1 cpus: 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 +node 1 size: 96757 MB +node 1 free: 2407 MB +node distances: +node 0 1 + 0: 10 21 + 1: 21 10 +``` diff --git a/results/classifier/118/graphic/878019 b/results/classifier/118/graphic/878019 new file mode 100644 index 000000000..430f9a1fd --- /dev/null +++ b/results/classifier/118/graphic/878019 @@ -0,0 +1,49 @@ +graphic: 0.937 +performance: 0.600 +device: 0.594 +mistranslation: 0.520 +peripherals: 0.505 +architecture: 0.424 +hypervisor: 0.402 +network: 0.399 +semantic: 0.395 +i386: 0.360 +permissions: 0.317 +user-level: 0.311 +boot: 0.310 +x86: 0.299 +PID: 0.290 +socket: 0.274 +debug: 0.255 +ppc: 0.254 +kernel: 0.251 +vnc: 0.247 +virtual: 0.220 +register: 0.183 +risc-v: 0.168 +arm: 0.164 +files: 0.156 +VMM: 0.148 +KVM: 0.119 +assembly: 0.102 +TCG: 0.067 + +0.15.1 black screen and 100% cpu on start + +Trying the freshly compiled 0.15.1 (command line: "qemu"), the window stays black, it uses 100% cpu, and can't be killed with ctrl-c, has to be killed with killall -9. + +Strace shows it's waiting on a futex forever? + +Build config: +./configure --prefix=/usr/local --interp-prefix=/usr/local/share/qemu \ +--enable-mixemu --disable-brlapi --enable-io-thread --audio-drv-list="oss alsa sdl" \ +--disable-opengl + + + +Triaging old bug tickets... I assume this problem has been fixed in newer versions of QEMU? Or can you still reproduce this behavior with the latest version? + +Feel free to close this. I think I moved to qemu-kvm, which worked. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/883 b/results/classifier/118/graphic/883 new file mode 100644 index 000000000..e1e1e4032 --- /dev/null +++ b/results/classifier/118/graphic/883 @@ -0,0 +1,57 @@ +graphic: 0.988 +x86: 0.986 +boot: 0.972 +debug: 0.964 +device: 0.933 +TCG: 0.889 +files: 0.872 +performance: 0.866 +user-level: 0.836 +arm: 0.832 +semantic: 0.825 +architecture: 0.820 +network: 0.820 +ppc: 0.813 +kernel: 0.799 +risc-v: 0.792 +PID: 0.777 +hypervisor: 0.728 +vnc: 0.725 +register: 0.724 +i386: 0.708 +permissions: 0.700 +socket: 0.694 +mistranslation: 0.692 +virtual: 0.622 +assembly: 0.545 +peripherals: 0.537 +VMM: 0.506 +KVM: 0.388 + +DRBG: could not allocate CTR cipher TFM handle: ctr(aes) +Description of problem: + +Steps to reproduce: +1. Install Debian in Qemu using the command: +``` +REM example to create disk +REM qemu-img create -f qcow2 debian-qcow2.img 32G + +qemu-system-x86_64.exe -hda debian-qcow2.img -cdrom debian-11.2.0-amd64-netinst.iso -boot d -m 8G -accel hax +``` + +2. Fight with installer and partitions to finally get this: + + +3. System boots and shows a bunch of FAILED messages with crypto error: + + + + +I am new at using Qemu so may need pointers to provide more information. + +The system seems to be working to some degree. + +Color me impressed!!! +Additional information: +Related: #880 diff --git a/results/classifier/118/graphic/888 b/results/classifier/118/graphic/888 new file mode 100644 index 000000000..fcffb5254 --- /dev/null +++ b/results/classifier/118/graphic/888 @@ -0,0 +1,37 @@ +graphic: 0.938 +device: 0.912 +TCG: 0.869 +mistranslation: 0.747 +semantic: 0.668 +performance: 0.649 +architecture: 0.644 +KVM: 0.640 +vnc: 0.637 +network: 0.577 +risc-v: 0.565 +kernel: 0.547 +files: 0.545 +socket: 0.527 +permissions: 0.507 +register: 0.502 +boot: 0.496 +hypervisor: 0.441 +virtual: 0.430 +VMM: 0.424 +debug: 0.415 +arm: 0.414 +peripherals: 0.339 +PID: 0.326 +user-level: 0.296 +ppc: 0.270 +i386: 0.269 +x86: 0.208 +assembly: 0.135 + +TCG <--> KVM behavior difference (TCG bug) +Description of problem: +This app couldn't start in TCG mode in QEMU 6.2, but with KVM everything is good. Until version 6.0 it also works with TCG. +As I checked - problem git commit is 5f9529006ea37560c97b05661a84472431d25b91. +Steps to reproduce: +1. Install Allplayer +2. Try to run it in TCG and KVM mode with QEMU 6.2 diff --git a/results/classifier/118/graphic/892 b/results/classifier/118/graphic/892 new file mode 100644 index 000000000..6dd89eaa3 --- /dev/null +++ b/results/classifier/118/graphic/892 @@ -0,0 +1,35 @@ +graphic: 0.930 +files: 0.924 +device: 0.828 +PID: 0.686 +architecture: 0.658 +mistranslation: 0.626 +permissions: 0.621 +network: 0.590 +semantic: 0.489 +socket: 0.488 +vnc: 0.427 +TCG: 0.374 +register: 0.364 +performance: 0.321 +ppc: 0.313 +VMM: 0.299 +boot: 0.290 +arm: 0.268 +assembly: 0.243 +risc-v: 0.140 +hypervisor: 0.127 +debug: 0.121 +peripherals: 0.111 +virtual: 0.108 +x86: 0.107 +kernel: 0.084 +user-level: 0.053 +i386: 0.044 +KVM: 0.024 + +Ensure qemu-storage-daemon builds, works and is included in win10 setup +Additional information: +- Job run on 20220315 "msys2-64bit build target" seems to have created binary: https://gitlab.com/qemu-project/qemu/-/jobs/2201739711 + - ```2456 [1324/1586] Linking target storage-daemon/qemu-storage-daemon.exe``` + - I hope it will be included in final distributed setup files diff --git a/results/classifier/118/graphic/893068 b/results/classifier/118/graphic/893068 new file mode 100644 index 000000000..b459b379d --- /dev/null +++ b/results/classifier/118/graphic/893068 @@ -0,0 +1,46 @@ +graphic: 0.922 +virtual: 0.897 +architecture: 0.777 +vnc: 0.719 +device: 0.691 +ppc: 0.611 +mistranslation: 0.576 +hypervisor: 0.570 +socket: 0.534 +semantic: 0.511 +network: 0.462 +permissions: 0.432 +arm: 0.415 +risc-v: 0.406 +PID: 0.391 +TCG: 0.369 +performance: 0.347 +VMM: 0.347 +peripherals: 0.335 +x86: 0.293 +register: 0.291 +files: 0.285 +i386: 0.260 +debug: 0.228 +kernel: 0.222 +KVM: 0.209 +boot: 0.185 +user-level: 0.144 +assembly: 0.070 + +Spanish keys { and [ did not work + +The keys { and [ did not work inside the virtualized enviorment (widnows 7). The problems happens ussing aqemu as a front end as well as invoking qemu-kvm from command line: + +qemu-kvm -m 8096 eclipse.img -smp cores=4,threads=2 -hdb ander.img -k es + +We have also notices this warning in the console: + +Warning: no scancode found for keysym 314 + +The host system is gentoo stable with some exceptions (mainly qemu-kvm-0.15.1-r1, gcc-4.6.2 and kernel-3.2_rc2) + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently version 2.8)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/894 b/results/classifier/118/graphic/894 new file mode 100644 index 000000000..c488f954c --- /dev/null +++ b/results/classifier/118/graphic/894 @@ -0,0 +1,61 @@ +graphic: 0.997 +socket: 0.976 +device: 0.976 +risc-v: 0.972 +performance: 0.964 +vnc: 0.955 +architecture: 0.954 +peripherals: 0.941 +debug: 0.932 +files: 0.928 +PID: 0.908 +permissions: 0.897 +network: 0.887 +ppc: 0.881 +virtual: 0.868 +TCG: 0.863 +user-level: 0.855 +kernel: 0.832 +arm: 0.765 +VMM: 0.727 +semantic: 0.711 +register: 0.692 +hypervisor: 0.669 +x86: 0.649 +boot: 0.609 +mistranslation: 0.592 +i386: 0.546 +assembly: 0.444 +KVM: 0.393 + +target/riscv64 qemu-iotests 040 failed +Description of problem: +I cross-compiled a riscv64 QEMU flavor based on the most updated code, then make check. Some qemu-iotests failed, 040 041 127 256 267. I mainly focused on test 040 and tried to find out what happened. +Steps to reproduce: +1. change directory to QEMU source tree root +2. ./configure --prefix=~/temp --target-list=riscv64-softmmu +3. make +4. cd build/tests/qemu-iotests/ +5. ./check -qcow2 040 + +Then a lot of error messages(please see attachment). The following log might hint the root cause I thought: +``` ++ Command: /home/qemu/qemu/build/tests/qemu-iotests/../../qemu-system-riscv64 -display none -vga none -chardev socket,id=mon,path=/tmp/tmpwhnx3jq0/qemu-28363-monitor.sock -mon chardev=mon,mode=control -qtest unix:path=/tmp/tmpwhnx3jq0/qemu-28363-qtest.sock -accel qtest -nodefaults -display none -accel qtest -drive if=none,id=drive0,file=/home/qemu/qemu/build/tests/qemu-iotests/scratch/test.img,format=qcow2,cache=writeback,aio=threads,node-name=top,backing.node-name=mid,backing.backing.node-name=base -device virtio-scsi -device scsi-hd,id=scsi0,drive=drive0 ++ Output: [I 1646574338.669217] OPENED ++qemu-system-riscv64: -device virtio-scsi: No 'PCI' bus found for device 'virtio-scsi-pci' +``` +The command had no '-machine' argument. For riscv64 target, 'spike' will be the default machine. Maybe 'spike' have no PCI bus? Then I tried to change it to 'virt' machine but failed, nothing new happen. +``` +QEMU_DEFAULT_MACHINE=virt ./check -qcow2 040 +``` +``` +QEMU_OPTIONS="-machine virt" ./check -qcow2 040 +``` +Last, I modified [testenv.py](https://gitlab.com/qemu-project/qemu/-/blob/master/tests/qemu-iotests/testenv.py#L239) and added one line in machine-map, all tests passed! +``` +('riscv64', 'virt'), +``` + +Is there any way to easy the issue or do I miss something? Thank you! +Additional information: +[zlog.riscv.xz](/uploads/cbbad7c5c256d2b49d220aa6425e2b17/zlog.riscv.xz) diff --git a/results/classifier/118/graphic/902413 b/results/classifier/118/graphic/902413 new file mode 100644 index 000000000..8feedb274 --- /dev/null +++ b/results/classifier/118/graphic/902413 @@ -0,0 +1,196 @@ +graphic: 0.803 +virtual: 0.701 +TCG: 0.687 +performance: 0.668 +KVM: 0.668 +register: 0.657 +permissions: 0.651 +user-level: 0.646 +hypervisor: 0.637 +debug: 0.627 +device: 0.620 +architecture: 0.609 +semantic: 0.598 +ppc: 0.586 +peripherals: 0.582 +risc-v: 0.577 +x86: 0.572 +arm: 0.551 +vnc: 0.525 +assembly: 0.523 +i386: 0.520 +mistranslation: 0.510 +VMM: 0.510 +socket: 0.493 +kernel: 0.472 +network: 0.467 +boot: 0.454 +PID: 0.449 +files: 0.411 + +qemu-i386-user on ARM host: wine hangs/spins when trying to run anything + +With qemu built from git from 217bfb445b54db618a30f3a39170bebd9fd9dbf2 and configured with './configure --target-list=i386-linux-user --static --interp-prefix=/home/pgriffais/natty-i386/', trying to run wine 1.3.15 from an Ubuntu 11.04 chroot results in hangs. If I run an i386 emulated wineserver, wineserver hangs in: + +0x600c7f8c in read () at ../sysdeps/unix/syscall-template.S:82 +82 ../sysdeps/unix/syscall-template.S: No such file or directory. + in ../sysdeps/unix/syscall-template.S +(gdb) bt +#0 0x600c7f8c in read () at ../sysdeps/unix/syscall-template.S:82 +#1 0x6004a316 in read (cpu_env=0x622c3ee8, num=3, arg1=6, arg2=1121255519, + arg3=1, arg4=134875664, arg5=1, arg6=1121255528, arg7=0, arg8=0) + at /usr/include/bits/unistd.h:45 +#2 do_syscall (cpu_env=0x622c3ee8, num=3, arg1=6, arg2=1121255519, arg3=1, + arg4=134875664, arg5=1, arg6=1121255528, arg7=0, arg8=0) + at /home/ubuntu/src/qemu/linux-user/syscall.c:4691 +#3 0x600262f0 in cpu_loop (env=0x622c3ee8) + at /home/ubuntu/src/qemu/linux-user/main.c:321 +#4 0x60026bbc in main (argc=<value optimized out>, + argv=<value optimized out>, envp=<value optimized out>) + at /home/ubuntu/src/qemu/linux-user/main.c:3817 + +While wine hangs in: + +0x600c84ac in recvmsg () at ../sysdeps/unix/syscall-template.S:82 +82 ../sysdeps/unix/syscall-template.S: No such file or directory. + in ../sysdeps/unix/syscall-template.S +(gdb) bt +#0 0x600c84ac in recvmsg () at ../sysdeps/unix/syscall-template.S:82 +#1 0x60041c4e in do_sendrecvmsg (fd=4, target_msg=<value optimized out>, + flags=1073741824, send=0) + at /home/ubuntu/src/qemu/linux-user/syscall.c:1834 +#2 0x600497ec in do_socketcall (cpu_env=<value optimized out>, num=102, + arg1=17, arg2=1122504544, arg3=2076831732, arg4=1122504568, + arg5=2076942688, arg6=1122504888, arg7=0, arg8=0) + at /home/ubuntu/src/qemu/linux-user/syscall.c:2235 +#3 do_syscall (cpu_env=<value optimized out>, num=102, arg1=17, + arg2=1122504544, arg3=2076831732, arg4=1122504568, arg5=2076942688, + arg6=1122504888, arg7=0, arg8=0) + at /home/ubuntu/src/qemu/linux-user/syscall.c:6085 +#4 0x600262f0 in cpu_loop (env=0x622c3f08) + at /home/ubuntu/src/qemu/linux-user/main.c:321 +#5 0x60026bbc in main (argc=<value optimized out>, + argv=<value optimized out>, envp=<value optimized out>) + at /home/ubuntu/src/qemu/linux-user/main.c:3817 + +However if I build wineserver 1.3.15 natively for ARM and run it on the host while wine is emulated, I get the following: + +root@tiberiusstation:/home/ubuntu# ./natty-i386/usr/bin/wine notepad +Unsupported ancillary data: 1/2 +Unsupported ancillary data: 1/2 +Unsupported ancillary data: 1/2 +err:process:__wine_kernel_init boot event wait timed out + +I assume the last one is due to wineboot.exe hanging. The main wine process hangs in there: + +cg_temp_new_internal_i32 (temp_local=<value optimized out>) + at /home/ubuntu/src/qemu/tcg/tcg.c:483 +483 } +(gdb) bt +#0 tcg_temp_new_internal_i32 (temp_local=<value optimized out>) + at /home/ubuntu/src/qemu/tcg/tcg.c:483 +#1 0x60052ac6 in tcg_temp_new_i32 (val=6) + at /home/ubuntu/src/qemu/tcg/tcg.h:442 +#2 tcg_const_i32 (val=6) at /home/ubuntu/src/qemu/tcg/tcg.c:530 +#3 0x6005ef0c in tcg_gen_shri_i32 (ot=2, op1=2, op2=7, is_right=1, + is_arith=0, s=<value optimized out>) + at /home/ubuntu/src/qemu/tcg/tcg-op.h:605 +#4 gen_shift_rm_im (ot=2, op1=2, op2=7, is_right=1, is_arith=0, + s=<value optimized out>) + at /home/ubuntu/src/qemu/target-i386/translate.c:1514 +#5 0x6006df90 in gen_shifti (s=0xbefea970, pc_start=<value optimized out>) + at /home/ubuntu/src/qemu/target-i386/translate.c:1946 +#6 disas_insn (s=0xbefea970, pc_start=<value optimized out>) + at /home/ubuntu/src/qemu/target-i386/translate.c:5397 +#7 0x60091758 in gen_intermediate_code_internal (env=0x625656f8, + tb=0x402cdf48) at /home/ubuntu/src/qemu/target-i386/translate.c:7825 +#8 gen_intermediate_code_pc (env=0x625656f8, tb=0x402cdf48) + at /home/ubuntu/src/qemu/target-i386/translate.c:7896 +#9 0x60054bf2 in cpu_restore_state (tb=0x402cdf48, env=0x62565690, + searched_pc=1617393812) at /home/ubuntu/src/qemu/translate-all.c:126 +#10 0x60091d9e in handle_cpu_signal (host_signum=<value optimized out>, + pinfo=<value optimized out>, puc=0xbefeab70) + at /home/ubuntu/src/qemu/user-exec.c:117 +#11 cpu_x86_signal_handler (host_signum=<value optimized out>, + pinfo=<value optimized out>, puc=0xbefeab70) + at /home/ubuntu/src/qemu/user-exec.c:458 +#12 0x6003c764 in host_signal_handler (host_signum=11, info=0xbefeaaf0, + puc=<value optimized out>) + at /home/ubuntu/src/qemu/linux-user/signal.c:492 +#13 <signal handler called> +#14 0x60677894 in static_code_gen_buffer () +#15 0x6000a260 in cpu_x86_exec (env=0x0) + at /home/ubuntu/src/qemu/cpu-exec.c:566 +#16 0x68953200 in ?? () +#17 0x68953200 in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack? + +Running the same version of wine through qemu-user-i386 running on an i386 host works fine with both wineserver and wine being emulated; that's the result I'm trying to achieve. + +Forgot to mention I had applied this patch also. Without this, emulated bash can't even start anything. + +Multithreaded programs don't work (reliably) in x86 user emulation mode. This is a known (longstanding) bug. +ARM hosts are also currently known to have problems (as stated in the qemu 1.0 release notes). + + +Thanks for your quick reply, Peter. + +Are there more specific bug entries tracking both the general problems you're talking about that I could monitor for progress, or any pointers on the direction to go to improve the situation? + +For ARM hosts (mostly being worked on): +https://bugs.launchpad.net/qemu/+bug/893208 +https://bugs.launchpad.net/qemu/+bug/883136 +https://bugs.launchpad.net/qemu/+bug/883133 +https://bugs.launchpad.net/qemu/+bug/870990 + +For x86 multithreaded (mostly *not* being worked on): +https://bugs.launchpad.net/qemu/+bug/668799 +https://bugs.launchpad.net/qemu/+bug/739785 + +At the moment the target-i386 front end is in status "Odd Fixes", which means it may get easy bug fixes but is unlikely to get enough attention to fix trickier problems like threading support. + + +Understood, thanks a lot for the pointers. From a quick skim it doesn't look like I'm directly running into any of these ARM host issues (yet). I'm hopeful that the i386 target will get increasing attention in the future as ARM devices get more widespread after x86 was the standard for so long. Out of curiosity, is the amd64 target in any better shape? + +QEMU has no separate amd64 target; it is all handled by target-i386. + + +See also +https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/758424 + +with QEMU expected to turn ver 2.0 in april I wonder this bug is still forgotten. +Bugs list on Peter Maydell's post and Dan Kegel's have fixes commited, and I see there are alternative patches from http://patchwork.ozlabs.org/patch/45206/ and http://repo.or.cz/w/qemu/agraf.git linked from http://wiki.winehq.org/ARM + +Good question, any news please? + +I just tried running x86 windows program, on x86 wine, on qemu-i386, all on an arm host. I am also experiencing a hung wine and wineserver. Was this bug ever fixed? + +We're actively working on improving QEMU's support for multithreaded guest programs in linux-user, but those changes are not yet complete. + + +I'm running qemu-2.5.0 on ARM, and wine (wine-1.7, 1.8, wine-staging) all seem to behave similarly; rename the winepreloader and you'll be able to run winecfg, notepad run, a few installers do run and the software runs. But Windows software LOVES using threads so you rapidly end up with some other installer firing off at least 6 or 8 threads and things break down. qemu-2.6.0, wine doesn't start. + +This is a tricky problem; current qemu has I/O threads, main thread (which is not fully thread-safe, this is what's being worked on...) and user threads; things work as long as some non-thread-safe part is not exercised too hard. + +I was beginning to despair, but there actually appears to be intense development activity on qemu branches on 3 fronts -- + +1) general qemu-multithreading (to make kvm qemu more scalable, let qemu-system-xxx actually use more than one CPU core, instead of simulating x CPU cores on one physical core as it does now). But this also involves fixing thread-safety problems in qemu that affect qemu-user-xxxx. + +2) Specifically getting qemu-i386-static threading work on ARM (a few ARM vendors.) + +3) Get qemu-arm-static threading working on x86. + +It looks like this should get into qemu in due time, maybe it'd be appropriate to call it qemu-3.0 at that point. + +You might want to retry wine with qemu-i386-static again now with qemu 2.7, which has a major thread/signal rework done. + +Running SkiFree (1.04 x32) on wine (1.8.3 x32) installed in a gentoo i686 chroot, all running via qemu-user-i386-static 1.7.0 on a raspberry pi 2 armv7 host works. It was almost playable at 1920x1080 too! + +winecfg worked, notepad.exe worked, and SkiFree worked too. + +So can we close this bug now, or is there still something left to do here? + +A year has passed since last update by Nathan Shearer, but status is labeled 'incomplete'. Please check if it's solved with wine 3.0 + +There hasn't been an update within a year, so let's assume this bug has been fixed. + diff --git a/results/classifier/118/graphic/906221 b/results/classifier/118/graphic/906221 new file mode 100644 index 000000000..7023157bc --- /dev/null +++ b/results/classifier/118/graphic/906221 @@ -0,0 +1,81 @@ +graphic: 0.957 +performance: 0.945 +kernel: 0.862 +user-level: 0.793 +mistranslation: 0.790 +peripherals: 0.765 +device: 0.704 +semantic: 0.686 +architecture: 0.681 +debug: 0.669 +PID: 0.663 +network: 0.650 +permissions: 0.640 +assembly: 0.518 +hypervisor: 0.498 +socket: 0.484 +files: 0.428 +register: 0.420 +boot: 0.414 +arm: 0.399 +vnc: 0.368 +ppc: 0.317 +risc-v: 0.281 +VMM: 0.275 +x86: 0.271 +TCG: 0.248 +i386: 0.231 +KVM: 0.221 +virtual: 0.197 + +USBDEVFS_CLEAR_HALT stall with USB-CDROM qemu-1.0 + +When connecting a USB DVD/CDROM drive to the linux host, it works fine and I can mount the inserted DVD properly and work with it. After unmounting the DVD and routing the USB drive to the linux guest (same kernel version), both host and guest become unresponsive and on the QEMU console I get the QEMU console flodded with the message: +USBDEVFS_CLEAR_HALT: Connection timed out +again and again, approx. each 10-20 seconds. + +When I unplug the device from the host, the message +USBDEVFS_CLEAR_HALT: No such device +comes up in one block at least 100 times (my scrollback history of the display is limited, so I cannot say how often it actually appreared) + +On the guest side linux, I see the following dmesg after having it routed from the host to the guest: +[ 160.292231] usb 1-2.1: new full speed USB device using uhci_hcd and address 5 +[ 160.475762] usb 1-2.1: configuration #1 chosen from 1 choice +[ 160.478553] scsi3 : SCSI emulation for USB Mass Storage devices +[ 160.479689] usb-storage: device found at 5 +[ 160.480121] usb-storage: waiting for device to settle before scanning +[ 165.494016] scsi 3:0:0:0: CD-ROM slimtype eTDU108 1 SL03 PQ: 0 ANSI: 0 + +then, the guest stalls and on the host side the USBDEVFS_CLEAR_HALT appears until I unplug the hardware from the host - pay also attention on the stalled dmesg timestamp! The "real" timegap between the last line above and the first line below is more than 20 seconds! + +[ 165.645735] usb 1-2.1: USB disconnect, address 5 +[ 165.663770] sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda pop-up +[ 165.664416] sr 3:0:0:0: Attached scsi CD-ROM sr0 +[ 165.664623] sr 3:0:0:0: Attached scsi generic sg1 type 5 +[ 165.665565] usb-storage: device scan complete + +The drive used is a self-powered LITEON External Slim DVD-ROM Drive (Model number eTDU108-02 1) +The power is not a problem, because the drive works fine on the host directly. + +Best regards, + +Erik + +Triaging old bug tickets ... Can you still reproduce this problem with the latest version of QEMU and the latest version of libusb? If so, could you please also provide the command line options that you used to start QEMU? + +Meanwhile it works. + +Thomas Huth wrote: +> Triaging old bug tickets ... Can you still reproduce this problem with +> the latest version of QEMU and the latest version of libusb? If so, +> could you please also provide the command line options that you used to +> start QEMU? +> +> ** Changed in: qemu +> Status: New => Incomplete +> + + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/909 b/results/classifier/118/graphic/909 new file mode 100644 index 000000000..92fc3be7f --- /dev/null +++ b/results/classifier/118/graphic/909 @@ -0,0 +1,41 @@ +graphic: 0.825 +device: 0.761 +architecture: 0.597 +user-level: 0.512 +files: 0.401 +mistranslation: 0.400 +socket: 0.377 +semantic: 0.323 +register: 0.288 +network: 0.283 +ppc: 0.283 +vnc: 0.262 +permissions: 0.238 +performance: 0.236 +boot: 0.233 +PID: 0.222 +x86: 0.188 +i386: 0.175 +debug: 0.150 +risc-v: 0.147 +arm: 0.133 +kernel: 0.125 +TCG: 0.114 +peripherals: 0.075 +virtual: 0.070 +VMM: 0.068 +hypervisor: 0.042 +assembly: 0.033 +KVM: 0.006 + +qemu-mipsn32(el) user mode emulator fails to execute any recently built n32 binaries +Description of problem: +**Note: Before trying to reproduce this issue, have a look at issue 843 - the binfmt-misc magic for n32 needs to be fixed.** + +Trying to chroot into a mips n32 installation fails with +``` +/bin/bash: error while loading shared libraries: /lib32/libc.so.6: cannot read file data +``` +however, bash, libc.so.6, and qemu all exist and have the proper abi + +The problem occurs for both big and little endian N32 ABI. O32 and N64 work fine. The same N32 binaries also work fine on native hardware. diff --git a/results/classifier/118/graphic/922076 b/results/classifier/118/graphic/922076 new file mode 100644 index 000000000..b7bde37bf --- /dev/null +++ b/results/classifier/118/graphic/922076 @@ -0,0 +1,81 @@ +graphic: 0.873 +user-level: 0.863 +PID: 0.858 +device: 0.846 +performance: 0.842 +register: 0.840 +ppc: 0.836 +files: 0.830 +peripherals: 0.821 +permissions: 0.820 +arm: 0.814 +architecture: 0.812 +boot: 0.810 +debug: 0.800 +kernel: 0.772 +hypervisor: 0.762 +x86: 0.762 +vnc: 0.756 +risc-v: 0.755 +network: 0.746 +semantic: 0.728 +TCG: 0.727 +VMM: 0.723 +socket: 0.706 +KVM: 0.681 +assembly: 0.680 +virtual: 0.557 +mistranslation: 0.381 +i386: 0.362 + +doesn't clear screen on boot + +When I start Linux in Qemu via "qemu -kernel /vmlinuz ...", opens Qemu window, it shows message "Starting Seabios (version 0.5.1-2010...)", and then Linux writes messages like "Loading, please wait..." on top of previous message! + +For example, I can see "Loading, please wait...on 0.5.1-2010...)" + +So, Qemu doesn't clean screan before booting OS. + +Moreover, when I start Linux via "qemu /disk-image", Qemu shows "Starting Seabios (version 0.5.1-2010...)", then switches to graphical mode, shows GRUB, then switches back to text mode and shows "Starting Seabios" again! And again Linux prints messages on top of Seabios messages, and we see a mix of symbols on screen. + +Also, I found another bug! I am learning now to write kernels. And I see that operator "*(char *)0xb8000 = 0" in C code of kernel doesn't clean first charaster of screen in Qemu in "-curses" mode! If I want to real clean this charaster, I must type "*(char *)0xb8000 = ' '". + +I attach a kernel (x86, multiboot) with this bug. Just type "make" (you need gcc) and "qemu -curses -kernel kernel". You will see that screen is not cleared, but kernel tries to clean it. If you change 0 to ' ', all will work! + + + +UPDATE: The second bug (which is started with "Also, I found another bug! I am learning...") is fixed in 1.4.0 + +About the first bug: screen clears on real hardware, so it is really bug. Also, it is reproducible with Qemu 1.4.0 and Qemu 5e3a0f418c4d57399778cee0b55aebfb663b6425. + +Does this problem still exist with the latest version of QEMU? Which interface type are you using (SDL, gtk, ...)? Can you please provide your full command line and build options? + +The bug still exists in qemu 2.7 (version present in my debian stretch). +I was not able reproduce the bug with booting kernel directly with 2.7 (-kernel ...), but booting disk image causes the bug. + +So, I have debian gnu/linux stretch amd64. debian package qemu-system-x86 1:2.7+dfsg-3+b1. I run my host system in qemu (i. e. I run in qemu same system that running on the host) using well known "-snapshot -drive file=/dev/sda" trick. Precise command line is: + +kdesudo -c "exec qemu-system-x86_64 -m 1024M -enable-kvm -daemonize -snapshot -drive file=/dev/sda,cache=none,format=raw" + +Qemu appears and I see usual "SeaBIOS (version 1.9.3-20161025_171302-gandalf)" as you can see at screenshot Screenshot_20161216_005817.png . + +Then qemu switches to grub. + +And then qemu switches to text mode back. And fsck prints to console: "/dev/sda2: recovering journal", but this words appears on top of that SeaBIOS self-adver., so we have the following words mixture: + +/dev/sda2: recovering journal25_171302-gandalf) + +I use sdl. I don't know build option, this is qemu from debian package + +This is Screenshot_20161216_005859.png , screenshot with grub + +And this is Screenshot_20161216_005917.png . Here (after grub) we see "recovering journal" on top of seabios string + + +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/87 + + diff --git a/results/classifier/118/graphic/936 b/results/classifier/118/graphic/936 new file mode 100644 index 000000000..0382acb47 --- /dev/null +++ b/results/classifier/118/graphic/936 @@ -0,0 +1,46 @@ +graphic: 0.981 +debug: 0.961 +boot: 0.961 +user-level: 0.862 +kernel: 0.838 +device: 0.781 +performance: 0.732 +architecture: 0.726 +register: 0.621 +x86: 0.619 +semantic: 0.587 +i386: 0.558 +ppc: 0.533 +risc-v: 0.531 +socket: 0.525 +vnc: 0.519 +peripherals: 0.513 +KVM: 0.468 +arm: 0.465 +permissions: 0.464 +network: 0.455 +PID: 0.449 +files: 0.447 +VMM: 0.431 +hypervisor: 0.413 +TCG: 0.381 +virtual: 0.242 +mistranslation: 0.198 +assembly: 0.191 + +Serial output mangled in terminal +Description of problem: +My hobby OS uses the serial port at `0x3f8` to log messages to QEMU's stdout. This used to work fine, I can even emit ANSI escape codes to get color output and it renders in my terminal as expected. I left this project for about a year and just returned to it with the latest version of QEMU. Now, all of the QEMU serial output from my OS in the terminal seems to be missing carriage returns and buffering strangely. It's as if every log line ends up on the same line in the stdout buffer, but with newlines (without returning to the start of the line) between them. For example (these aren't my real logs but demonstrate the issue): +``` +[KERNEL] startup + [KERNEL] initializing heap + [KERNEL] initializing drivers + [KERNEL] ready! +``` +Also, when QEMU exits, I notice that my shell indicates that the last command's output didn't end in a newline which is strange. + +I tried debugging this myself by piping the output to a file and inspecting it in a hex editor, but it looks like just normal newlines in the output. I tried piping the output to `tr '\n' '\r\n'` to add carriage returns, but that ends up rendering all the output on a single line which resets to the first column every line. I tried sending the output to a file and watching the file, but it seems to get buffered and the data only shows up once QEMU exits. My best guess is that the output hasn't changed, but this new version of QEMU is changing some kind of buffering setting on its output which is causing this, but I'm really not sure what's going on. +Steps to reproduce: +I can provide the boot image if that would be helpful to reproduce. +Additional information: + diff --git a/results/classifier/118/graphic/945 b/results/classifier/118/graphic/945 new file mode 100644 index 000000000..3c6f11fff --- /dev/null +++ b/results/classifier/118/graphic/945 @@ -0,0 +1,40 @@ +graphic: 0.910 +device: 0.865 +performance: 0.733 +vnc: 0.706 +semantic: 0.678 +architecture: 0.661 +PID: 0.645 +mistranslation: 0.627 +network: 0.625 +kernel: 0.547 +debug: 0.540 +risc-v: 0.453 +permissions: 0.429 +boot: 0.395 +ppc: 0.345 +socket: 0.339 +TCG: 0.326 +register: 0.282 +user-level: 0.267 +arm: 0.267 +VMM: 0.218 +files: 0.203 +virtual: 0.173 +hypervisor: 0.169 +assembly: 0.145 +peripherals: 0.127 +i386: 0.124 +KVM: 0.026 +x86: 0.020 + +For QEMU 7.0.0-rc1, nbd-server-add fails with qcow2 image with iothread in migration context +Description of problem: +Upon adding the drive for NBD (via QMP), there is an error message +````kvm: ../block.c:3657: bdrv_open_child: Assertion `qemu_in_main_thread()' failed.```` +and then the process aborts. +Steps to reproduce: +1. Create image: `qemu-img create -f qcow2 /root/target-disk.qcow2 4G` +2. Start QEMU as mentioned above. +3. Issue `nbd-server-start` QMP command (I used type unix). +4. Issue `nbd-server-add` command for the single disk. diff --git a/results/classifier/118/graphic/946 b/results/classifier/118/graphic/946 new file mode 100644 index 000000000..f55bdf1a9 --- /dev/null +++ b/results/classifier/118/graphic/946 @@ -0,0 +1,42 @@ +graphic: 0.855 +device: 0.842 +semantic: 0.715 +network: 0.669 +files: 0.577 +vnc: 0.536 +debug: 0.524 +kernel: 0.464 +PID: 0.447 +socket: 0.423 +ppc: 0.422 +performance: 0.413 +register: 0.386 +i386: 0.375 +boot: 0.368 +risc-v: 0.350 +x86: 0.333 +architecture: 0.322 +VMM: 0.299 +user-level: 0.288 +mistranslation: 0.257 +TCG: 0.256 +hypervisor: 0.255 +KVM: 0.252 +permissions: 0.246 +peripherals: 0.224 +arm: 0.171 +virtual: 0.135 +assembly: 0.074 + +qemu-img can't create qcow2 file on nfs path，which report error(Image is not in qcow2 format) +Description of problem: +I mount a nfs disk on my host,and use qemu-img to create a qcow2 file on this nfs path,but it not work,i have no idea,This problem has come up before in red-hat community: +[BUGID:1817640](https://bugzilla.redhat.com/show_bug.cgi?id=1817640#) +Steps to reproduce: + + +**strace file:** +[qemu-img-strace.log](/uploads/85517b7550ba1ea459f85cfd37b74332/qemu-img-strace.log) + +See form this strace file,in the line 1077,we can see pread64 read result is empty,it casuse the error,but i don't know why the resulut is empty. + diff --git a/results/classifier/118/graphic/946043 b/results/classifier/118/graphic/946043 new file mode 100644 index 000000000..77d6c437b --- /dev/null +++ b/results/classifier/118/graphic/946043 @@ -0,0 +1,47 @@ +graphic: 0.916 +device: 0.809 +performance: 0.640 +semantic: 0.635 +debug: 0.613 +mistranslation: 0.606 +peripherals: 0.548 +ppc: 0.517 +user-level: 0.391 +arm: 0.389 +boot: 0.346 +vnc: 0.284 +PID: 0.283 +architecture: 0.266 +register: 0.251 +network: 0.220 +socket: 0.202 +kernel: 0.194 +risc-v: 0.172 +permissions: 0.168 +x86: 0.139 +VMM: 0.130 +virtual: 0.117 +i386: 0.114 +TCG: 0.099 +files: 0.095 +hypervisor: 0.045 +assembly: 0.040 +KVM: 0.020 + +Serial Named Pipe Unrecognized Windows 7 + +I created a named pipe serial hardware and supplied '/tmp/debug' which I created using mkfifo + +This is the snippet from ps -aux +-chardev pipe,id=charserial0,path=/tmp/debug -device isa-serial,chardev=charserial0,id=serial0 + +failure@ubuntu1:~$ ls -al /tmp/debug* +prwxrwxrwx 1 jgp jgp 0 2012-03-03 18:40 /tmp/debug +prwxrwxrwx 1 jgp jgp 0 2012-03-03 18:40 /tmp/debug.in + +However inside the Windows 7 guest (even after a restart) nothing is recognized. Even after going through the add legacy hardware motions it's still not picked up. + +Which version of QEMU were you using? Can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/graphic/958 b/results/classifier/118/graphic/958 new file mode 100644 index 000000000..9edd712e7 --- /dev/null +++ b/results/classifier/118/graphic/958 @@ -0,0 +1,43 @@ +graphic: 0.935 +device: 0.896 +boot: 0.889 +network: 0.848 +semantic: 0.628 +ppc: 0.592 +mistranslation: 0.583 +peripherals: 0.562 +vnc: 0.557 +debug: 0.528 +PID: 0.524 +files: 0.430 +TCG: 0.413 +register: 0.356 +socket: 0.317 +risc-v: 0.305 +architecture: 0.276 +x86: 0.270 +user-level: 0.261 +performance: 0.258 +VMM: 0.251 +arm: 0.227 +kernel: 0.224 +permissions: 0.218 +i386: 0.167 +virtual: 0.148 +hypervisor: 0.096 +KVM: 0.063 +assembly: 0.037 + +qemu-system-sparc crashes on floppy access +Description of problem: +qemu-system-sparc crashes when accessing the emulated floppy drive of the guest system. +Steps to reproduce: +1. wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.2/sparc/installation/bootfs/boot.fs.gz +2. gunzip boot.fs.gz +3. qemu-system-sparc -nographic boot.fs +4. Select option "3) floppy" +5. qemu-systems-sparc crashes with the messages: +``` + Ejecting floppy disk + Segmentation fault (core dumped) +``` diff --git a/results/classifier/118/graphic/959 b/results/classifier/118/graphic/959 new file mode 100644 index 000000000..f0541d54e --- /dev/null +++ b/results/classifier/118/graphic/959 @@ -0,0 +1,39 @@ +graphic: 0.972 +device: 0.872 +semantic: 0.726 +architecture: 0.686 +performance: 0.684 +files: 0.678 +mistranslation: 0.595 +permissions: 0.568 +vnc: 0.556 +register: 0.416 +boot: 0.409 +debug: 0.406 +PID: 0.286 +risc-v: 0.268 +arm: 0.262 +virtual: 0.244 +ppc: 0.205 +hypervisor: 0.172 +TCG: 0.159 +user-level: 0.159 +VMM: 0.136 +network: 0.120 +socket: 0.100 +x86: 0.087 +i386: 0.033 +assembly: 0.033 +kernel: 0.031 +peripherals: 0.026 +KVM: 0.004 + +100% CPU utilization when the guest is idle (FreeBSD on M1 Mac) +Description of problem: +100% CPU utilization when the guest is idle. +Steps to reproduce: +1. Download the FreeBSD qcow2 image and decompress it: https://download.freebsd.org/releases/VM-IMAGES/13.0-RELEASE/aarch64/Latest/ +2. Execute the above command. +3. The QEMU process consumes 100% CPU. +4. + diff --git a/results/classifier/118/graphic/962 b/results/classifier/118/graphic/962 new file mode 100644 index 000000000..b481abebf --- /dev/null +++ b/results/classifier/118/graphic/962 @@ -0,0 +1,49 @@ +graphic: 0.948 +device: 0.826 +mistranslation: 0.821 +ppc: 0.735 +vnc: 0.722 +semantic: 0.694 +performance: 0.612 +files: 0.592 +network: 0.586 +architecture: 0.532 +PID: 0.527 +risc-v: 0.527 +i386: 0.525 +socket: 0.512 +user-level: 0.509 +hypervisor: 0.401 +x86: 0.395 +arm: 0.361 +boot: 0.358 +debug: 0.357 +VMM: 0.349 +TCG: 0.308 +register: 0.285 +peripherals: 0.284 +permissions: 0.283 +kernel: 0.274 +virtual: 0.228 +KVM: 0.213 +assembly: 0.098 + +Screenshot images are skewed +Description of problem: +1. Start a guest with SPICE +2. Connect with a SPICE client +3. Resize screen to a width that is not a multiple of 4 (e. g. 487x956) +4. Take a screenshot + +The screenshot ppm file will contain the actual dimensions in the header, e. g. +``` +P6 +487 956 +255 +``` +but the image data will contain more than that (e. g. 488 * 956 * 3 bytes). +As a result, when displaying the image it appears skewed. +Steps to reproduce: +See above. +Additional information: +I'm not familiar with qemu code nor the pixman library, but I assume that in [this line](https://gitlab.com/qemu-project/qemu/-/blob/bc6ec396d471d9e4aae7e2ff8b72e11da9a97665/ui/console.c#L316) `get_stride` is wrong. Instead, it should write `width*3` bytes. diff --git a/results/classifier/118/graphic/980 b/results/classifier/118/graphic/980 new file mode 100644 index 000000000..7c15ee87b --- /dev/null +++ b/results/classifier/118/graphic/980 @@ -0,0 +1,46 @@ +graphic: 0.983 +performance: 0.928 +semantic: 0.890 +architecture: 0.890 +PID: 0.877 +files: 0.874 +device: 0.845 +hypervisor: 0.806 +debug: 0.779 +vnc: 0.777 +virtual: 0.771 +permissions: 0.717 +user-level: 0.712 +register: 0.636 +ppc: 0.636 +socket: 0.616 +boot: 0.595 +network: 0.586 +VMM: 0.570 +peripherals: 0.569 +kernel: 0.549 +risc-v: 0.523 +TCG: 0.512 +arm: 0.446 +i386: 0.421 +x86: 0.393 +mistranslation: 0.383 +KVM: 0.334 +assembly: 0.030 + +Binary emulation of a Solaris-8-compiled dynamically linked C program gives a bus error immediately on startup when running with qemu-sparc +Description of problem: +I am currently trying to use binary emulation to run a dynamically-linked executable C program that was written and compiled on a Solaris 8 VM. However, when I do so, I immediately get a bus error, and I'm not sure what the cause is. Below I'll delineate all of the steps I took to recreate this. +Steps to reproduce: +1. Start Solaris 8 VM (this was done via QEMU, actually, and there are no issues here) +2. Write a simple `.c` program. +3. Compile that program with `/usr/local/bin/gcc`. The name of the program is `binary_emulation`. +4. Test program on the VM to ensure functionality. +5. Stop VM. +6. Mount `.qcow2` on the Linux host so I can easily extract files from it. +7. Copy the entire `/` directory off to `~/binary_emulation/target` +8. Copy `binary_emulation` to a separate directory. +9. `cd` to `.../qemu/build` +10. Run `./qemu-sparc -L ~/binary_emulation/target ~/binary_emulation/binary_emulation` +Additional information: +# diff --git a/results/classifier/118/graphic/983 b/results/classifier/118/graphic/983 new file mode 100644 index 000000000..ac78e5916 --- /dev/null +++ b/results/classifier/118/graphic/983 @@ -0,0 +1,38 @@ +graphic: 0.901 +device: 0.884 +socket: 0.815 +files: 0.741 +permissions: 0.645 +risc-v: 0.624 +vnc: 0.611 +register: 0.545 +boot: 0.541 +network: 0.511 +TCG: 0.511 +arm: 0.467 +debug: 0.418 +semantic: 0.390 +user-level: 0.378 +VMM: 0.361 +PID: 0.325 +i386: 0.278 +ppc: 0.275 +performance: 0.242 +kernel: 0.233 +x86: 0.202 +mistranslation: 0.165 +peripherals: 0.121 +virtual: 0.114 +KVM: 0.079 +architecture: 0.073 +hypervisor: 0.046 +assembly: 0.037 + +Qemu Wiki Database Query Error +Steps to reproduce: +1. Access the Qemu Wiki. https://wiki.qemu.org/Main_Page +2. Type "serial" in the search bar and hit the enter key. +3. Crash ensues. +Additional information: +Crash info attached. +[qemu_wiki_bug.txt](/uploads/06fb534ea65c486f72dce14e75c834bd/qemu_wiki_bug.txt) diff --git a/results/classifier/118/graphic/988 b/results/classifier/118/graphic/988 new file mode 100644 index 000000000..ff9b938aa --- /dev/null +++ b/results/classifier/118/graphic/988 @@ -0,0 +1,31 @@ +graphic: 0.991 +device: 0.837 +risc-v: 0.682 +mistranslation: 0.557 +performance: 0.403 +ppc: 0.377 +VMM: 0.280 +TCG: 0.261 +boot: 0.210 +debug: 0.209 +arm: 0.159 +vnc: 0.159 +virtual: 0.150 +PID: 0.132 +user-level: 0.126 +network: 0.121 +peripherals: 0.102 +hypervisor: 0.100 +i386: 0.097 +permissions: 0.088 +KVM: 0.056 +register: 0.048 +x86: 0.047 +socket: 0.045 +semantic: 0.019 +architecture: 0.007 +kernel: 0.004 +files: 0.003 +assembly: 0.003 + +Cirrus video, graphical corruption, bad fonts diff --git a/results/classifier/118/graphic/992 b/results/classifier/118/graphic/992 new file mode 100644 index 000000000..16e7b0a3e --- /dev/null +++ b/results/classifier/118/graphic/992 @@ -0,0 +1,50 @@ +graphic: 0.819 +device: 0.731 +semantic: 0.653 +ppc: 0.633 +PID: 0.414 +architecture: 0.406 +risc-v: 0.365 +boot: 0.327 +performance: 0.322 +debug: 0.288 +socket: 0.274 +network: 0.265 +permissions: 0.262 +kernel: 0.259 +mistranslation: 0.246 +vnc: 0.240 +files: 0.224 +register: 0.206 +arm: 0.151 +TCG: 0.150 +VMM: 0.149 +peripherals: 0.143 +i386: 0.135 +user-level: 0.130 +hypervisor: 0.126 +x86: 0.114 +KVM: 0.095 +virtual: 0.074 +assembly: 0.028 + +qemu-system-riscv64: Some ROM regions are overlapping When memory set <= 16 +Description of problem: + +Steps to reproduce: +1. Build the qemu +2. run `./build/riscv64-softmmu/qemu-system-riscv64 --nographic -machine virt -m 16` +3. got error message: +``` +qemu-system-riscv64: Some ROM regions are overlapping +These ROM regions might have been loaded by direct user request or by default. +They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory. +Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses. + +The following two regions overlap (in the memory address space): + /home/shiroko/Developments/qemu/build/pc-bios/opensbi-riscv64-generic-fw_dynamic.bin (addresses 0x0000000080000000 - 0x0000000080019b50) + fdt (addresses 0x0000000080000000 - 0x0000000080100000) +``` +Additional information: +Using `./build/riscv64-softmmu/qemu-system-riscv64 --nographic -machine virt -m 17` could bootup and seen OpenSBI messages. +This problem appears on qemu-system-riscv32 too. diff --git a/results/classifier/118/graphic/995 b/results/classifier/118/graphic/995 new file mode 100644 index 000000000..92579a1b9 --- /dev/null +++ b/results/classifier/118/graphic/995 @@ -0,0 +1,41 @@ +graphic: 0.989 +architecture: 0.967 +semantic: 0.960 +device: 0.875 +performance: 0.858 +x86: 0.856 +vnc: 0.829 +arm: 0.760 +files: 0.703 +ppc: 0.674 +VMM: 0.672 +debug: 0.669 +register: 0.642 +assembly: 0.641 +virtual: 0.600 +PID: 0.586 +permissions: 0.581 +user-level: 0.580 +kernel: 0.579 +peripherals: 0.573 +socket: 0.556 +i386: 0.549 +risc-v: 0.499 +hypervisor: 0.479 +network: 0.446 +TCG: 0.351 +boot: 0.332 +mistranslation: 0.325 +KVM: 0.260 + +Segfault when saving VM snapshot via QEMU monitor on MIPS and MIPSEL +Description of problem: +When entering the QEMU monitor using Ctrl-A then C, and running the savevm QEMU command, the emulator hangs for a while and then exits with a segfault. This occurs on MIPS and MIPSEL system emulators using the same command line arguments. ARM32, aarch64 and x86_64 emulators don't seem to have this problem. I haven't tested it on any other architectures as I don't have kernel or drive images for them. `qemu-img` seems to work fine with the QCOW2 images used for this test, I was able to create and load offline snapshots from them. The images were created from raw EXT2 filesystem images produced by Buildroot, using `qemu-img convert`. +Steps to reproduce: +1. Start the QEMU system emulator for MIPS/MIPSEL with the given command line. +2. Enter the QEMU monitor with Ctrl-A, C. +3. Run `savevm <vm name>`. +Additional information: +I tried logging what QEMU was doing with the `-D ./log.txt` command line option, but the produced log file was empty. + +If you need me to send you the kernel image files and QCOW2 images used, I would be happy to do so. |