11 files changed, 435 insertions, 0 deletions
diff --git a/results/classifier/108/other/104 b/results/classifier/108/other/104
new file mode 100644
index 00000000..3114714d
--- /dev/null
+++ b/results/classifier/108/other/104
@@ -0,0 +1,16 @@
+performance: 0.892
+graphic: 0.850
+device: 0.740
+network: 0.231
+debug: 0.215
+permissions: 0.207
+other: 0.149
+boot: 0.147
+PID: 0.116
+vnc: 0.102
+files: 0.099
+semantic: 0.035
+socket: 0.021
+KVM: 0.008
+
+Cursor jumps on shape change with vmware vga
diff --git a/results/classifier/108/other/1041 b/results/classifier/108/other/1041
new file mode 100644
index 00000000..94781feb
--- /dev/null
+++ b/results/classifier/108/other/1041
@@ -0,0 +1,46 @@
+graphic: 0.899
+other: 0.696
+device: 0.653
+performance: 0.595
+files: 0.458
+PID: 0.418
+debug: 0.412
+network: 0.412
+semantic: 0.396
+socket: 0.342
+vnc: 0.291
+permissions: 0.279
+boot: 0.197
+KVM: 0.091
+
+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/108/other/1042 b/results/classifier/108/other/1042
new file mode 100644
index 00000000..03f47958
--- /dev/null
+++ b/results/classifier/108/other/1042
@@ -0,0 +1,35 @@
+device: 0.796
+performance: 0.759
+PID: 0.722
+semantic: 0.712
+graphic: 0.709
+vnc: 0.643
+socket: 0.612
+other: 0.592
+boot: 0.591
+permissions: 0.569
+network: 0.449
+files: 0.435
+debug: 0.432
+KVM: 0.217
+
+windows 10 guest freezes the host on shutdown
+Description of problem:
+Windows 10 guest sometimes freezes the QEMU host when shutting down.
+
+There has been a bug reported about this in the past here:
+https://bugs.launchpad.net/qemu/+bug/1580459
+
+I am also using PCI Passthrough with an NVIDIA GPU.
+Some users have claimed to have fixed this issue by enabling Message Signaled-based Interrupts-mode on the PCI Devices the (GPU/HDMI-AUDIO). I have have these enabled and confirmed they are enabled, but the issue still persists.
+
+This bug has been effecting me for over a year, I just never bothered to look deeper into it after I seen the issue still persists after enabling the MSI stuff.
+
+There is something I noticed about this issue. Basically, it appears that I can mostly avoid the issue entirely, by making sure that as the guest is shutting down, that I move the mouse a bit.
+The host almost never freezes if I do this, and only happens very rarely.
+But if I start a shutdown, and just don't move the mouse at all, it is very likely the host will lock up, requiring a complete reboot. I am pretty sure the mouse movement, should be a big clue, because I can consistently reproduce the issue. The issue itself does not (atleast) for me appear to be tied to how long the VM is running or if gaming on it or not, though I have not thoroughly tested this.
+
+I have gone through various kernel/qemu/libvirt updates, the issue occurs in all of them, and has been an issue from the very beginning of my setup.
+Steps to reproduce:
+1. Start Windows 10 guest.
+2. Shutdown Windows 10 guest
diff --git a/results/classifier/108/other/1042561 b/results/classifier/108/other/1042561
new file mode 100644
index 00000000..fd0ddf40
--- /dev/null
+++ b/results/classifier/108/other/1042561
@@ -0,0 +1,52 @@
+KVM: 0.794
+device: 0.721
+performance: 0.621
+PID: 0.595
+network: 0.531
+graphic: 0.525
+semantic: 0.460
+other: 0.455
+socket: 0.448
+boot: 0.388
+vnc: 0.373
+permissions: 0.336
+files: 0.298
+debug: 0.232
+
+Guest has no "xsave" feature with parameter "-cpu qemu64,+xsave" in qemu command line.
+
+Environment:
+------------
+Host OS (ia32/ia32e/IA64):ia32e
+Guest OS (ia32/ia32e/IA64):ia32e
+Guest OS Type (Linux/Windows):Linux
+kvm.git Commit:1a577b72475d161b6677c05abe57301362023bb2
+qemu-kvm Commit:98f1f30a89901c416e51cc70c1a08d9dc15a2ad4
+Host Kernel Version:3.5.0-rc1
+Hardware:Romley-EP, Ivy-bridge
+
+
+Bug detailed description:
+--------------------------
+Guest has no "xsave" feature when create guest with parameter "-cpu qemu64,+xsave,+avx" in qemu command line, but the guest has avx feature.
+When starting a guest with parameter "-cpu host" in qemu command line, the guest has 'avx' and 'xsave' features (as /proc/cpuinfo shows).
+
+This is not a recent regression; it exists for a long time.
+
+Reproduce steps:
+----------------
+1. qemu-system-x86_64 -m 1024 -smp 2 -hda rhel6u3.img -cpu qemu64,+xsave
+2. cat /proc/cpuinfo | grep xsave     ( check guest's xsave feature)
+
+Current result:
+----------------
+The guest has no xsave feature
+
+Expected result:
+----------------
+The guest has xsave feature
+
+Basic root-causing log:
+
+xsave needs level >= 13, and qemu64 has level=4. Try "-cpu qemu64,+xsave,+avx,level=13".
+
diff --git a/results/classifier/108/other/1043 b/results/classifier/108/other/1043
new file mode 100644
index 00000000..d98bf74d
--- /dev/null
+++ b/results/classifier/108/other/1043
@@ -0,0 +1,25 @@
+device: 0.913
+graphic: 0.833
+performance: 0.831
+boot: 0.718
+debug: 0.702
+semantic: 0.669
+files: 0.595
+PID: 0.573
+permissions: 0.534
+network: 0.477
+vnc: 0.398
+socket: 0.253
+other: 0.246
+KVM: 0.027
+
+QEMU cpu max doesnot work on Windows 11 with ryzen processor and whpx
+Description of problem:
+- System does not boot.
+- WHPX: setting APIC emulation mode in the hypervisor
+- Windows Hypervisor Platform accelerator is operational
+- whpx: injection failed, MSI (0, 0) delivery: 0, dest_mode: 0, trigger mode: 0, vector: 0, lost (c0350005)
+- qemu: WHPX: Unexpected VP exit code 4
+Steps to reproduce:
+1. Windows 11 / Ryzen
+2. qemu-system-x86_64.exe --accel whpx --cpu max
diff --git a/results/classifier/108/other/1044 b/results/classifier/108/other/1044
new file mode 100644
index 00000000..4656d508
--- /dev/null
+++ b/results/classifier/108/other/1044
@@ -0,0 +1,16 @@
+device: 0.657
+performance: 0.415
+other: 0.408
+semantic: 0.406
+vnc: 0.397
+graphic: 0.389
+PID: 0.359
+network: 0.346
+socket: 0.326
+boot: 0.309
+debug: 0.253
+permissions: 0.226
+KVM: 0.064
+files: 0.054
+
+Warning: libevent-loop-base.a the table of contents is empty
diff --git a/results/classifier/108/other/1045 b/results/classifier/108/other/1045
new file mode 100644
index 00000000..ebac9fd5
--- /dev/null
+++ b/results/classifier/108/other/1045
@@ -0,0 +1,41 @@
+KVM: 0.818
+graphic: 0.763
+debug: 0.738
+semantic: 0.695
+device: 0.570
+performance: 0.488
+vnc: 0.431
+socket: 0.424
+network: 0.421
+PID: 0.404
+boot: 0.374
+permissions: 0.365
+files: 0.340
+other: 0.238
+
+When a break point is set, nested virtualization sees "kvm_queue_exception: Assertion `!env->exception_has_payload' failed."
+Description of problem:
+I am debugging XMHF and LHV using QEMU + KVM. I found that if I set a break point using GDB, QEMU will crash when LHV is booting. The message is
+```
+qemu-system-i386: ../../../target/i386/kvm/kvm.c:678: kvm_queue_exception: Assertion `!env->exception_has_payload' failed.
+```
+
+The address of the break point is arbitrary. The break point does not need to hit. So I chose 0 as the address in this bug report.
+Steps to reproduce:
+1. Start QEMU using `qemu-system-i386 -m 512M -gdb tcp::1234 -smp 2 -cpu Haswell,vmx=yes -enable-kvm -serial stdio -drive media=disk,file=1.img,index=1 -drive media=disk,file=2.img,index=2 -S`
+2. In another shell, start GDB using `gdb --ex 'target remote :::1234' --ex 'hb *0' --ex c`
+3. See many serial output lines. The tail of the output is
+    ```
+    CPU #0: vcpu_vaddr_ptr=0x01e06080, esp=0x01e11000
+    CPU #1: vcpu_vaddr_ptr=0x01e06540, esp=0x01e15000
+    BSP(0x00): Rallying APs...
+    BSP(0x00): APs ready, doing DRTM...
+    LAPIC base and status=0xfee00900
+    Sending INIT IPI to all APs...
+    ```
+4. See assertion error in QEMU
+    ```
+    qemu-system-i386: ../target/i386/kvm/kvm.c:645: kvm_queue_exception: Assertion `!env->exception_has_payload' failed.
+    ```
+Additional information:
+This bug was first incorrectly filed in KVM's bug tracker at <https://bugzilla.kernel.org/show_bug.cgi?id=216002>.
diff --git a/results/classifier/108/other/1047470 b/results/classifier/108/other/1047470
new file mode 100644
index 00000000..3066ac1b
--- /dev/null
+++ b/results/classifier/108/other/1047470
@@ -0,0 +1,83 @@
+graphic: 0.869
+socket: 0.863
+network: 0.847
+device: 0.841
+PID: 0.833
+permissions: 0.809
+debug: 0.806
+semantic: 0.803
+vnc: 0.750
+other: 0.746
+KVM: 0.714
+boot: 0.706
+performance: 0.688
+files: 0.485
+
+qemu/kvm hangs reading from serial console
+
+This is for a qemu-kvm running on RHEL 5, so it's pretty old,
+but i think the problem still exists in 1.2
+
+We have conman running on our hosts, connecting to the
+kvm/qemu's using
+    virsh console
+which just opens up the console /dev/pts/slave that qemu
+opens up when run with options
+    -nographic
+    -serial mon:pty
+
+Sometimes virsh console exits and then qemu locks up.
+My guess is that something like this happens:
+
+virsh console exits
+qemu does a select() on /dev/ptmx (and other FDs)
+select() returns the FD of /dev/ptmx in the read-fdset
+qemu does a read()
+read() returns -1 (EIO)
+qemu does other stuff for a while
+select() ... /dev/ptmx
+read() .. EIO
+other stuff
+select() ... read() ... select() ... read() ... select()
+conman starts a new virsh console that connects
+qemu does a read()
+read() blocks b/c there is now a writer on the tty slave
+
+So i don't see any way around this, given the sorta rudi-
+mentary semantics of TTY IO on Linux (not that i know of
+any platform that does it better ... ?), except ...
+
+maybe qemu should
+    fcntl(master_fd, F_SETFL, flags | O_NONBLOCK) 
+in qemu-char.c:qemu_char_open_pty()
+and be prepared to handle E_WOULDBLOCK|E_AGAIN in 
+qemu-char.c:fd_chr_read() ... ?
+
+--buck
+
+[*] i think, b/c in the old version we are running, sometimes
+    the guest spits out the
+        ^]
+    character to its console, and virsh console reads it and
+    doesn't check to see if its from stdin or the pty and exits, 
+    which, i think, can be fixed like this:
+
+--- libvirt-0.8.2/tools/console.c.ctrl_close_bracket_handling_fix       2012-09-06 10:30:43.606997191 -0400
++++ libvirt-0.8.2/tools/console.c       2012-09-06 10:34:52.154000464 -0400
+@@ -155,6 +155,7 @@ int vshRunConsole(const char *tty) {
+
+                 /* Quit if end of file, or we got the Ctrl-] key */
+                 if (!got ||
++                    fds[i].fd == STDIN_FILENO &&
+                     (got == 1 &&
+                      buf[0] == CTRL_CLOSE_BRACKET))
+                     goto done;
+
+Can you still reproduce this problem with the latest version of QEMU? There have been quite a bunch of fixes in this area in the latest versions...
+
+i don't use kvm/qemu any more and so don't have a means
+to determine if this is still an issue or not so please
+presume fixed, i guess
+
+OK, thanks for your answer!
+
diff --git a/results/classifier/108/other/1047576 b/results/classifier/108/other/1047576
new file mode 100644
index 00000000..4dc0355e
--- /dev/null
+++ b/results/classifier/108/other/1047576
@@ -0,0 +1,84 @@
+vnc: 0.880
+KVM: 0.853
+other: 0.847
+graphic: 0.844
+device: 0.820
+semantic: 0.811
+PID: 0.793
+debug: 0.786
+performance: 0.785
+permissions: 0.783
+boot: 0.782
+socket: 0.751
+network: 0.728
+files: 0.676
+
+qemu unittest emulator failure on latest git master
+
+Running the emulator unittest, using the cmdline:
+
+16:01:30 INFO | Running emulator
+16:01:30 INFO | Running qemu command (reformatted):
+16:01:30 INFO | /home/lmr/Code/autotest.git/autotest/client/tests/virt/kvm/qemu 
+16:01:30 INFO |     -S 
+16:01:30 INFO |     -name 'unittest_vm' 
+16:01:30 INFO |     -nodefaults 
+16:01:30 INFO |     -chardev socket,id=hmp_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20120907-155940-WomlFZY3,server,nowait 
+16:01:30 INFO |     -mon chardev=hmp_id_humanmonitor1,mode=readline 
+16:01:30 INFO |     -chardev socket,id=serial_id_20120907-155940-WomlFZY3,path=/tmp/serial-20120907-155940-WomlFZY3,server,nowait 
+16:01:30 INFO |     -device isa-serial,chardev=serial_id_20120907-155940-WomlFZY3 
+16:01:30 INFO |     -chardev socket,id=seabioslog_id_20120907-155940-WomlFZY3,path=/tmp/seabios-20120907-155940-WomlFZY3,server,nowait 
+16:01:30 INFO |     -device isa-debugcon,chardev=seabioslog_id_20120907-155940-WomlFZY3,iobase=0x402 
+16:01:30 INFO |     -m 512 
+16:01:30 INFO |     -smp 2,cores=1,threads=1,sockets=2 
+16:01:30 INFO |     -kernel '/home/lmr/Code/autotest.git/autotest/client/tests/virt/kvm/unittests/emulator.flat' 
+16:01:30 INFO |     -vnc :0 
+16:01:30 INFO |     -chardev file,id=testlog,path=/tmp/testlog-20120907-155940-WomlFZY3 
+16:01:30 INFO |     -device testdev,chardev=testlog 
+16:01:30 INFO |     -rtc base=utc,clock=host,driftfix=none  
+16:01:30 INFO |     -boot order=cdn,once=c,menu=off   
+16:01:30 INFO |     -S 
+16:01:30 INFO |     -enable-kvm
+
+We get
+
+16:01:32 INFO | Waiting for unittest emulator to complete, timeout 600, output in /tmp/testlog-20120907-155940-WomlFZY3
+16:01:32 INFO | [qemu output] KVM internal error. Suberror: 1
+16:01:32 INFO | [qemu output] emulation failure
+16:01:32 INFO | [qemu output] RAX=ffffffffffffeff8 RBX=ffffffffffffe000 RCX=fffffffffffff000 RDX=000000000044d2b0
+16:01:32 INFO | [qemu output] RSI=000000000044c9fa RDI=000000000044e370 RBP=ffffffffffffeff8 RSP=000000000044d2b0
+16:01:32 INFO | [qemu output] R8 =000000000000000a R9 =00000000000003f8 R10=0000000000000000 R11=0000000000000000
+16:01:32 INFO | [qemu output] R12=ffffffffffffe000 R13=000000001fff6000 R14=000000001fff5000 R15=0000000000000000
+16:01:32 INFO | [qemu output] RIP=0000000000400a89 RFL=00010002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
+16:01:32 INFO | [qemu output] ES =0010 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
+16:01:32 INFO | [qemu output] CS =0008 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA]
+16:01:32 INFO | [qemu output] SS =0000 0000000000000000 ffffffff 00000000
+16:01:32 INFO | [qemu output] DS =0010 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
+16:01:32 INFO | [qemu output] FS =0010 0000000000000000 ffffffff 00c09300 DPL=0 DS   [-WA]
+16:01:32 INFO | [qemu output] GS =0010 000000000044c370 ffffffff 00c09300 DPL=0 DS   [-WA]
+16:01:32 INFO | [qemu output] LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
+16:01:32 INFO | [qemu output] TR =0048 000000000040a452 0000ffff 00008b00 DPL=0 TSS64-busy
+16:01:32 INFO | [qemu output] GDT=     000000000040a00a 00000447
+16:01:32 INFO | [qemu output] IDT=     0000000000000000 00000fff
+16:01:32 INFO | [qemu output] CR0=80010011 CR2=0000000000000000 CR3=000000001ffff000 CR4=00000020
+16:01:32 INFO | [qemu output] DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
+16:01:32 INFO | [qemu output] DR6=00000000ffff0ff0 DR7=0000000000000400
+16:01:32 INFO | [qemu output] EFER=0000000000000500
+16:01:32 INFO | [qemu output] Code=88 77 00 49 8d 84 24 f8 0f 00 00 48 89 e2 48 89 e9 48 89 c5 <c9> 48 87 e2 48 87 e9 48 81 f9 99 88 77 00 0f 94 c0 48 39 d5 40 0f 94 c6 40 0f b6 f6 21 c6
+
+More logs will be attached to this bug report.
+
+
+
+Adding relevant qemu and unittest versions
+
+software_version_qemu_kvm=git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git:master:4c3e02beed9878a5f760eeceb6cd42c475cf0127
+software_version_kvm_unit_tests=git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git:master:09b657b6d3a80d0424b8b370462a77d284117926
+
+
+Triaging old bug tickets ... Can you still reproduce this problem with the latest version of QEMU?
+
+This doesn't reproduce with the latest version of QEMU, you may close it.
+
+Thanks for checking again!
+
diff --git a/results/classifier/108/other/1048 b/results/classifier/108/other/1048
new file mode 100644
index 00000000..8e50c1f4
--- /dev/null
+++ b/results/classifier/108/other/1048
@@ -0,0 +1,21 @@
+device: 0.825
+graphic: 0.725
+other: 0.563
+network: 0.527
+files: 0.518
+socket: 0.518
+vnc: 0.502
+performance: 0.376
+semantic: 0.338
+boot: 0.301
+PID: 0.288
+debug: 0.187
+permissions: 0.155
+KVM: 0.045
+
+usb/ohci does not reset HccaPad1 after frame number update.
+Description of problem:
+When the OHCI controller's framenumber is incremented, HccaPad1 register should be set to zero. Ref OHCI Spec 4.4.1.
+Relevant code section: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/usb/hcd-ohci.c#L1201
+
+ReactOS uses hccaPad1 to determine if the OHCI hardware is running, consequently it fails this check in current qemu master.
diff --git a/results/classifier/108/other/1049 b/results/classifier/108/other/1049
new file mode 100644
index 00000000..07f72add
--- /dev/null
+++ b/results/classifier/108/other/1049
@@ -0,0 +1,16 @@
+device: 0.915
+performance: 0.695
+vnc: 0.531
+network: 0.448
+PID: 0.443
+other: 0.370
+KVM: 0.350
+socket: 0.288
+graphic: 0.286
+debug: 0.237
+semantic: 0.224
+boot: 0.197
+permissions: 0.184
+files: 0.117
+
+Have DeviceRealize return boolean indicating error