7 files changed, 280 insertions, 0 deletions
diff --git a/results/classifier/108/other/85 b/results/classifier/108/other/85
new file mode 100644
index 000000000..daa884d3f
--- /dev/null
+++ b/results/classifier/108/other/85
@@ -0,0 +1,16 @@
+device: 0.829
+network: 0.781
+semantic: 0.708
+socket: 0.696
+vnc: 0.606
+debug: 0.567
+performance: 0.509
+files: 0.478
+boot: 0.445
+graphic: 0.413
+other: 0.383
+PID: 0.357
+KVM: 0.307
+permissions: 0.099
+
+info registers' command leads to segfault with -M none
diff --git a/results/classifier/108/other/850 b/results/classifier/108/other/850
new file mode 100644
index 000000000..530712bda
--- /dev/null
+++ b/results/classifier/108/other/850
@@ -0,0 +1,74 @@
+vnc: 0.697
+KVM: 0.694
+graphic: 0.691
+permissions: 0.690
+other: 0.690
+device: 0.683
+performance: 0.647
+files: 0.639
+debug: 0.631
+network: 0.622
+socket: 0.607
+semantic: 0.584
+PID: 0.582
+boot: 0.541
+
+virtio-gpu: bogus descriptor or out of resources
+Description of problem:
+The guest which I use have 1GB memory, also the guest contains 8GB swap, when I open lot of applications in the guest, the guest kernel starts using swap, after some time, I get this error
+
+<code>
+qemu-system-x86_64: virtio: bogus descriptor or out of resources
+</code>
+
+I tried to see which virtio device causing this issue, it seems this issue is happening in "virtio-gpu", I modified the sources ad added this line to see the device name
+
+virtio.c:1312: virtio_error(vdev, "virtio: %s: bogus descriptor or out of resources", vdev->name);
+Steps to reproduce:
+1. create a vm with 8GB swap
+2. run that vm with above mentioned commandline (memory = 1MB)
+3. open huge applications which eats ram in guest
+Additional information:
+Seems suddenly condition "if (!memory_access_is_direct(mr, is_write))" [physmem.c:1385] becomes true, this is the stack trace when "if (qatomic_xchg(&bounce.in_use, true)) {" [physmem.c:1386] line gets hit for the first time,
+
+<code>
+#0  address_space_map (as=<optimized out>, addr=addr@entry=45251811299328, plen=plen@entry=0x7fffffff7e30, is_write=is_write@entry=false, attrs=..., attrs@entry=...) at ../qemu-6.2.0/softmmu/physmem.c:3186
+#1  0x0000555555cb8cf4 in dma_memory_map (dir=DMA_DIRECTION_TO_DEVICE, len=<synthetic pointer>, addr=45251811299328, as=<optimized out>) at /home/mohan/Downloads/qemu/src/qemu-6.2.0/include/sysemu/dma.h:202
+#2  virtqueue_map_desc
+    (vdev=vdev@entry=0x5555579d3bb0, p_num_sg=p_num_sg@entry=0x7fffffff7ed8, addr=addr@entry=0x7fffffff7f70, iov=0x7fffffff9f70, max_num_sg=max_num_sg@entry=1024, is_write=is_write@entry=false, pa=45251811299328, sz=65536) at ../qemu-6.2.0/hw/virtio/virtio.c:1307
+#3  0x0000555555cb8f9e in virtqueue_packed_pop (vq=<optimized out>, sz=<optimized out>) at ../qemu-6.2.0/hw/virtio/virtio.c:1624
+#4  0x00007fffec0b329e in virtio_gpu_gl_handle_ctrl (vdev=<optimized out>, vq=0x7fffdced6010) at ../qemu-6.2.0/hw/display/virtio-gpu-gl.c:77
+#5  0x0000555555f74134 in aio_bh_call (bh=0x555556d02bc0) at ../qemu-6.2.0/util/async.c:141
+#6  aio_bh_poll (ctx=ctx@entry=0x555556958750) at ../qemu-6.2.0/util/async.c:169
+#7  0x0000555555f5f784 in aio_dispatch (ctx=0x555556958750) at ../qemu-6.2.0/util/aio-posix.c:381
+#8  0x0000555555f73d63 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../qemu-6.2.0/util/async.c:311
+#9  0x00007ffff787dfd3 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
+#10 0x0000555555f80129 in glib_pollfds_poll () at ../qemu-6.2.0/util/main-loop.c:232
+#11 os_host_main_loop_wait (timeout=0) at ../qemu-6.2.0/util/main-loop.c:255
+#12 main_loop_wait (nonblocking=nonblocking@entry=0) at ../qemu-6.2.0/util/main-loop.c:531
+#13 0x0000555555c48fe5 in qemu_main_loop () at ../qemu-6.2.0/softmmu/runstate.c:726
+#14 0x000055555597b664 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../qemu-6.2.0/softmmu/main.c:50
+</code>
+<br/>
+address_space_map() returns valid pointer in the first hit, but it returns NULL on the second hit because qatomic_xchg(bounce.in_use, true) returns true, I think it should suppose to return false. this is the stack trace when it happens for the second time
+<br/>
+<code>
+#0  address_space_map (as=<optimized out>, addr=addr@entry=45251811303424, plen=plen@entry=0x7fffffff7e30, is_write=is_write@entry=false, attrs=..., attrs@entry=...) at ../qemu-6.2.0/softmmu/physmem.c:3186
+#1  0x0000555555cb8cf4 in dma_memory_map (dir=DMA_DIRECTION_TO_DEVICE, len=<synthetic pointer>, addr=45251811303424, as=<optimized out>) at /home/mohan/Downloads/qemu/src/qemu-6.2.0/include/sysemu/dma.h:202
+#2  virtqueue_map_desc
+    (vdev=vdev@entry=0x5555579d3bb0, p_num_sg=p_num_sg@entry=0x7fffffff7ed8, addr=addr@entry=0x7fffffff7f70, iov=0x7fffffff9f70, max_num_sg=max_num_sg@entry=1024, is_write=is_write@entry=false, pa=45251811303424, sz=61440) at ../qemu-6.2.0/hw/virtio/virtio.c:1307
+#3  0x0000555555cb8f9e in virtqueue_packed_pop (vq=<optimized out>, sz=<optimized out>) at ../qemu-6.2.0/hw/virtio/virtio.c:1624
+#4  0x00007fffec0b329e in virtio_gpu_gl_handle_ctrl (vdev=<optimized out>, vq=0x7fffdced6010) at ../qemu-6.2.0/hw/display/virtio-gpu-gl.c:77
+#5  0x0000555555f74134 in aio_bh_call (bh=0x555556d02bc0) at ../qemu-6.2.0/util/async.c:141
+#6  aio_bh_poll (ctx=ctx@entry=0x555556958750) at ../qemu-6.2.0/util/async.c:169
+#7  0x0000555555f5f784 in aio_dispatch (ctx=0x555556958750) at ../qemu-6.2.0/util/aio-posix.c:381
+#8  0x0000555555f73d63 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../qemu-6.2.0/util/async.c:311
+#9  0x00007ffff787dfd3 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
+#10 0x0000555555f80129 in glib_pollfds_poll () at ../qemu-6.2.0/util/main-loop.c:232
+#11 os_host_main_loop_wait (timeout=0) at ../qemu-6.2.0/util/main-loop.c:255
+#12 main_loop_wait (nonblocking=nonblocking@entry=0) at ../qemu-6.2.0/util/main-loop.c:531
+#13 0x0000555555c48fe5 in qemu_main_loop () at ../qemu-6.2.0/softmmu/runstate.c:726
+#14 0x000055555597b664 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../qemu-6.2.0/softmmu/main.c:50
+</code>
+<br/>
+It seems virtqueue_packed_pop() receives one desc with desc.len=65536 (or -1) which should not suppose to happen. I dont know why this is happening
diff --git a/results/classifier/108/other/853 b/results/classifier/108/other/853
new file mode 100644
index 000000000..c20e8c6ba
--- /dev/null
+++ b/results/classifier/108/other/853
@@ -0,0 +1,25 @@
+device: 0.740
+semantic: 0.733
+other: 0.721
+files: 0.669
+graphic: 0.511
+network: 0.507
+vnc: 0.374
+socket: 0.321
+debug: 0.304
+permissions: 0.253
+boot: 0.230
+performance: 0.220
+PID: 0.158
+KVM: 0.136
+
+Quaint English in qemu-options.hx
+Description of problem:
+qemu-options.hx contains grammar that a native English-speaking person would never use. I had to read a sentence in that file very slowly and more than once to understand it.
+Steps to reproduce:
+1. Install QEMU
+2. Run a command to display documentation that includes qemu-options.hx for instance "man qemu-system-x86_64"
+3. Observe "This option defines where is connected the drive ..."
+4. Scratch head, figure out that "This option defines where the drive is connected ..." is the meaning.
+Additional information:
+It is very difficult to report QEMU documentation bugs.
diff --git a/results/classifier/108/other/854 b/results/classifier/108/other/854
new file mode 100644
index 000000000..22fb334d2
--- /dev/null
+++ b/results/classifier/108/other/854
@@ -0,0 +1,77 @@
+debug: 0.879
+permissions: 0.863
+vnc: 0.861
+other: 0.858
+performance: 0.853
+device: 0.851
+semantic: 0.837
+PID: 0.833
+network: 0.832
+files: 0.832
+graphic: 0.829
+KVM: 0.829
+socket: 0.793
+boot: 0.746
+
+rsync to ext4-fs on dynamic expanding qcow2 fails
+Description of problem:
+Firstly, this issue does not seem to happen when the virtual-disk is dd-raw-img or fixed qcow2 (preallocation=falloc). The guest-kernel has multiple tracebacks during rsync to dst folder on ext4-fs on qcow2. 
+I ctrl-C-ed the rsync process after the first traceback, which happened after copying around 52 GiB. 
+On a previous run, wherein I had let it continue, somewhere near the end, around 83 GiB, dmesg would bloat with a zillion trace-backs and stall. The sha256sum verify seems to have succeeded for all files copied so far and correctly gives error "Failed open or read" on subsequent files that were not copied. 
+In this test, the partial-rsync completed files were not corrupted. However, as qemu's disk emulation allocates blocks, qemu may be inducing paging-bugs into the guest-kernel. Paging issues like these may also lead to corruption. The guest-kernel should see the same full emulated disk regardless of whether qemu provided a fixed disk, dynamic disk, or even a different type of virtual-disk-format. The guest-vm should not detect/perceive any difference between them.
+
+There may be upcoming trouble round the 5.17 corner.
+
+It is beyond me to figure out if this is due to
+* qemu-6.2 block code
+* guest-kernel ( kernel-5.17 folio/page management or ntfs3 driver or something else )  
+
+It may be necessary to ascertain if this is a new bug on account of qemu not being ready for folio type page-management or a bug in upstream kernel.org. My apologies in advance if it turns out that this is not a qemu bug.
+
+There there does seem to be some problem with qemu dealing with expanding virtual disks, with bugs that show up only if the underlying virtual-disk is dynamic and expanding.
+
+I just think that storage/block-code should be made rock solid with a much higher priority than adding new features.
+If storage code is undependable, then qemu/vm cannot be used, and there is no point in any other feature. qcow2 in particular is the qemu's native virtual-disk format.
+
+I had to stop testing on Issue #727 , Issue #814 , on account of what I thought was a bug in 5.15 kernels. I filed the bug as "fs/ntfs3: page_cache_ra_unbounded on rsync from ntfs3 to ext4" https://bugzilla.kernel.org/show_bug.cgi?id=215460 . I assume that bug is different because it happens even on raw image. 
+
+setup is as follows:
+- Host: Fedora-35 with kernel-5.17.0-0.rc2.83.fc35.x86_64 self-built from srpm ( https://koji.fedoraproject.org/koji/buildinfo?buildID=1910212 )
+- Guest: Fedora-Workstation-Live-x86_64-Rawhide-20220201.n.0.iso with 5.17.0-0.rc2.83.fc36.x86_64 ( https://koji.fedoraproject.org/koji/buildinfo?buildID=1910892 )  
+- qemu: 6.2.0 (qemu-6.2.0-2.fc35.1) self-built from srpm  ( https://koji.fedoraproject.org/koji/buildinfo?buildID=1897713 )
+- hda: qcow2(dyn) with ext4 and also 4 combinations of raw_img/fixed_qcow2 with ext4/ntfs3
+- hdb: vhdx, ntfs3 (pre-prepared sgdata https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694 )  
+
+qcow2 image is created as follows:
+``` 
+[root@sirius ~]# qemu-img create -f qcow2 /mnt/a16/gkpics01.qcow2 99723771904
+Formatting '/mnt/a16/gkpics01.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=99723771904 lazy_refcounts=off refcount_bits=16 
+```
+
+qemu command is as follows:
+``` 
+[root@sirius ~]# qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot "d" -cdrom "/vol/15KJ_Images/transcend/Fedora-Workstation-Live-x86_64-Rawhide-20220201.n.0.iso" -hda "/mnt/a16/gkpics01.raw" -hdb "/vol/15KJ_Images/test/sgdata.vhdx" -device "virtio-vga" -display "gtk,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" 
+```
+Steps to reproduce:
+1. Inside booted vm, use gdisk to partition /dev/sda1 if necessary
+2. ```dmesg -w (in another pty)``` 
+3. ```mkfs.ext4 /dev/sda1 -L fs_gkpics001``` 
+4. ```mkdir /mnt/a /mnt/b``` 
+5. ```mount -t ext4 /dev/sda1 /mnt/a``` 
+6. ```mount -t ntfs3 /dev/sdb2 /mnt/b```
+7. rsync testdata: ```(sdate=`date` ; echo "$sdate" ; cd /mnt/b ; rsync -avH ./photos001 /mnt/a | tee /tmp/rst.txt ; echo "$sdate" ; date )``` 
+8. ```umount /mnt/a ; ``` 
+9. ```mount -t ext4 /dev/sda1 /mnt/a``` 
+10. verify: ```(sdate=`date` ; echo "$sdate" ; cd /mnt/a/photos001 ; sha256sum -c ./find.CHECKSUM --quiet ; echo "$sdate" ; date )``` 
+11. ```umount /mnt/a ; umount /mnt/b;```
+Additional information:
+**Test attempts**
+- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/rawimg/ext4 with vhdx/ntfs3/sgdata 
+- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/rawimg/ntfs3 with vhdx/ntfs3/sgdata 
+- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/qcow2(fixed)/ext4 with vhdx/ntfs3/sgdata 
+- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/qcow2(fixed)/ntfs3 with vhdx/ntfs3/sgdata 
+- Bug **does** happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/**qcow2(dyn)**/ext4 with vhdx/ntfs3/sgdata 
+- Bug does not happen directly on Host with 5.17.0-0.rc2.83/ExFat with ntfs3/sgdata
+- Bug does not happen directly on Host with 5.17.0-0.rc2.83/ntfs3 with ntfs3/sgdata
+
+Also filed a linux-kernel bug titled "during rsync, vm guest kernel trace arising from memcg_kmem_charge_page alloc_pages" https://bugzilla.kernel.org/show_bug.cgi?id=215563
diff --git a/results/classifier/108/other/855630 b/results/classifier/108/other/855630
new file mode 100644
index 000000000..370fdf026
--- /dev/null
+++ b/results/classifier/108/other/855630
@@ -0,0 +1,46 @@
+semantic: 0.773
+other: 0.737
+PID: 0.700
+files: 0.685
+graphic: 0.652
+performance: 0.531
+device: 0.512
+vnc: 0.498
+socket: 0.418
+network: 0.337
+boot: 0.331
+permissions: 0.301
+debug: 0.276
+KVM: 0.150
+
+Cant Run Wine (posix not nptl) past 0.14.1
+
+when trying to build qemu I can build with ./configure --static --enable-sdl --target-list=i386-linux-user just fine with 0.12.5
+
+But when I try to go on 0.13.0 or higher (tested on 0.15.0) it will say it cant find libSDL.
+
+Tried with arm and x86 versions of Ubuntu 9.10 and 11.04. Same on all 4 tests.
+
+I found I could run posix wine on 12.5 but I cant go higher for posix wine because of that libSDL.
+
+Oh I forgot to mention, you can compile qemu 0.13.0 or higher without the --static, and with --enable-sdl just fine all the way up to 0.15.5
+
+But with --static, it cant find libSDL.
+
+0.12.5 Can do this just fine. It can do --static --enable-sdl together, and find my libSDL, and run posix wine.
+
+SDL is only of any use for the system emulation targets. If you're just building a linux-user target there is no point passing --enable-sdl to configure. Just use "./configure --static --target-list=i386-linux-user".
+
+
+Thanks! Your right I disabled SDL and wine posix still worked on 12.5.. but not on 13.0 or higher.. I thought SDL was the reason why. ??? =) 
+
+Wine posix isnt fun to get. http://www.onsitedentalsystems.com/wine.tar.gz 
+
+the binary files in there run fine for qemu-i386 0.12.5 but nothing higher then that..  I dont know why.  
+
+Triaging old bug tickets... The problem with the SDL static linking has likely been fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5f37e6d4a7b22ccf1bb8fa4
+Can you still reproduce the other 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/108/other/858 b/results/classifier/108/other/858
new file mode 100644
index 000000000..0f876fffd
--- /dev/null
+++ b/results/classifier/108/other/858
@@ -0,0 +1,26 @@
+device: 0.905
+debug: 0.877
+graphic: 0.854
+vnc: 0.705
+files: 0.649
+PID: 0.646
+semantic: 0.528
+permissions: 0.507
+network: 0.479
+socket: 0.427
+performance: 0.368
+boot: 0.360
+KVM: 0.074
+other: 0.062
+
+qemu-system-x86_64: WHPX: Unexpected VP exit code 4
+Description of problem:
+Qemu closes and  prints following message:
+
+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-system-x86_64: WHPX: Unexpected VP exit code 4
+Steps to reproduce:
+1. build OVMF firmware from edk2
+2. run cmd : qemu-system-x86_64 -accel whpx --bios D:\Projects\FW\uefi\edk2\Build\OvmfX64\DEBUG_VS2019\FV\OVMF.fd
diff --git a/results/classifier/108/other/859 b/results/classifier/108/other/859
new file mode 100644
index 000000000..a4065011c
--- /dev/null
+++ b/results/classifier/108/other/859
@@ -0,0 +1,16 @@
+device: 0.896
+other: 0.609
+graphic: 0.441
+semantic: 0.418
+performance: 0.392
+permissions: 0.388
+boot: 0.330
+network: 0.230
+PID: 0.217
+vnc: 0.184
+files: 0.175
+socket: 0.082
+debug: 0.050
+KVM: 0.032
+
+PowerPC's Virtual Open Firmware uses an unsupported instruction in older CPUs