summary refs log tree commit diff stats
path: root/results/classifier/108/other/1827
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/other/182716
-rw-r--r--results/classifier/108/other/182700548
-rw-r--r--results/classifier/108/other/182777239
-rw-r--r--results/classifier/108/other/182787163
4 files changed, 166 insertions, 0 deletions
diff --git a/results/classifier/108/other/1827 b/results/classifier/108/other/1827
new file mode 100644
index 00000000..179512f8
--- /dev/null
+++ b/results/classifier/108/other/1827
@@ -0,0 +1,16 @@
+graphic: 0.828
+device: 0.718
+performance: 0.447
+PID: 0.402
+permissions: 0.355
+semantic: 0.355
+boot: 0.329
+debug: 0.220
+network: 0.099
+vnc: 0.072
+other: 0.047
+socket: 0.029
+KVM: 0.011
+files: 0.010
+
+Turn DPRINTF macro use into tracepoints
diff --git a/results/classifier/108/other/1827005 b/results/classifier/108/other/1827005
new file mode 100644
index 00000000..c6c05eb1
--- /dev/null
+++ b/results/classifier/108/other/1827005
@@ -0,0 +1,48 @@
+graphic: 0.889
+boot: 0.857
+other: 0.732
+device: 0.675
+semantic: 0.622
+performance: 0.522
+permissions: 0.481
+PID: 0.469
+files: 0.398
+vnc: 0.388
+socket: 0.361
+network: 0.358
+debug: 0.352
+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/108/other/1827772 b/results/classifier/108/other/1827772
new file mode 100644
index 00000000..3f512e51
--- /dev/null
+++ b/results/classifier/108/other/1827772
@@ -0,0 +1,39 @@
+graphic: 0.718
+device: 0.608
+vnc: 0.347
+PID: 0.317
+semantic: 0.268
+boot: 0.249
+network: 0.238
+other: 0.238
+permissions: 0.225
+performance: 0.221
+socket: 0.217
+files: 0.200
+debug: 0.126
+KVM: 0.054
+
+[RFC] dma buf: support sprite plane
+
+QEMU does not support sprite/overlay in DMA-buf mode for Intel gvt vGPUs. Some use cases relies on sprite plane support, e.g. hw accelerated video playback in Windows 10 guest.
+
+To support this feature, functions in both kernel and QEMU should be implemented:
+
+- query support for plane info in kernel: 
+  in vgpu_get_plane_info() of drm/i915/gvt/dmabuf.c, calls to intel_vgpu_decode_sprite_plane() shall be made;
+
+- struct to hold VFIODMABuf object in QEMU:
+  in struct VFIODisplay of include/hw/vfio/vfio-common.h;
+- copying of data in QEMU:
+  in vfio_display_get_dmabuf() of hw/vfio/display.c;
+- drawing of sprite plane in QEMU:
+  in vfio_display_dmabuf_update() of hw/vfio/display.c;
+
+
+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/169
+
+
diff --git a/results/classifier/108/other/1827871 b/results/classifier/108/other/1827871
new file mode 100644
index 00000000..8a87e27a
--- /dev/null
+++ b/results/classifier/108/other/1827871
@@ -0,0 +1,63 @@
+other: 0.939
+graphic: 0.923
+permissions: 0.922
+semantic: 0.915
+debug: 0.903
+performance: 0.896
+device: 0.894
+boot: 0.870
+PID: 0.836
+files: 0.831
+vnc: 0.829
+socket: 0.770
+KVM: 0.744
+network: 0.712
+
+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.
+