2 files changed, 63 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/device/1926 b/results/classifier/gemma3:12b/device/1926
new file mode 100644
index 00000000..82a83dbc
--- /dev/null
+++ b/results/classifier/gemma3:12b/device/1926
@@ -0,0 +1,25 @@
+
+Spice: handle_dev_destroy_surface_wait: condition `msg->surface_id == 0' failed (DoS via assert failure)
+Description of problem:
+Assert failure in libspice-server was found during fuzzing qxl-vga device.
+
+```plaintext
+qemu-system-x86_64: Spice: ../server/red-worker.cpp:367:handle_dev_destroy_surface_wait: condition `msg->surface_id == 0' failed
+Аварийный останов
+```
+Steps to reproduce:
+1. This bug can be reroduced with 
+
+   ```plaintext
+   cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -M \
+   pc -nodefaults -vga qxl -qtest stdio
+   outl 0xcf8 0x8000101c
+   outl 0xcfc 0xc000
+   outl 0xcf8 0x80001004
+   outw 0xcfc 0x01
+   outl 0xc00b 0x01000000
+   EOF
+   ```
+2. This bug is in another place from https://gitlab.com/qemu-project/qemu/-/issues/1829, please pay attention to it. It has to be solved, because it interferes with further fuzzing process
+Additional information:
+As I mentioned, I really need this bug to be solved, because fuzzing qxl-vga device gets less efficient. I suggested to report it here, not in spice-server, because this bug can be on the QEMU side.
diff --git a/results/classifier/gemma3:12b/device/1926231 b/results/classifier/gemma3:12b/device/1926231
new file mode 100644
index 00000000..e05b65fe
--- /dev/null
+++ b/results/classifier/gemma3:12b/device/1926231
@@ -0,0 +1,38 @@
+
+SCSI passthrough of SATA cdrom -> errors & performance issues
+
+qemu 5.0, compiled from git
+
+I am passing through a SATA cdrom via SCSI passthrough, with this libvirt XML:
+
+    <hostdev mode='subsystem' type='scsi' managed='no' sgio='unfiltered' rawio='yes'>
+      <source>
+        <adapter name='scsi_host3'/>
+        <address bus='0' target='0' unit='0'/>
+      </source>
+      <alias name='hostdev0'/>
+      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+    </hostdev>
+
+It seems to mostly work, I have written discs with it, except I am getting errors that cause reads to take about 5x as long as they should, under certain circumstances.  It appears to be based on the guest's read block size.
+
+I found that if on the guest I run, say `dd if=$some_large_file bs=262144|pv > /dev/null`, `iostat` and `pv` disagree about how much is being read by a factor of about 2.  Also many kernel messages like this happen on the guest:
+
+[  190.919684] sr 0:0:0:0: [sr0] tag#160 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s
+[  190.919687] sr 0:0:0:0: [sr0] tag#160 Sense Key : Aborted Command [current] 
+[  190.919689] sr 0:0:0:0: [sr0] tag#160 Add. Sense: I/O process terminated
+[  190.919691] sr 0:0:0:0: [sr0] tag#160 CDB: Read(10) 28 00 00 18 a5 5a 00 00 80 00
+[  190.919694] blk_update_request: I/O error, dev sr0, sector 6460776 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
+
+If I change to bs=131072 the errors stop and performance is normal.
+
+(262144 happens to be the block size ultimately used by md5sum, which is how I got here)
+
+I also ran strace on the qemu process while it was happening, and noticed SG_IO calls like this:
+
+21748 10:06:29.330910 ioctl(22, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, cmdp="\x28\x00\x00\x12\x95\x5a\x00\x00\x80\x00", mx_sb_len=252, iovec_count=0, dxfer_len=262144, timeout=4294967295, flags=SG_FLAG_DIRECT_IO <unfinished ...>
+21751 10:06:29.330976 ioctl(22, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, cmdp="\x28\x00\x00\x12\x94\xda\x00\x00\x02\x00", mx_sb_len=252, iovec_count=0, dxfer_len=4096, timeout=4294967295, flags=SG_FLAG_DIRECT_IO <unfinished ...>
+21749 10:06:29.331586 ioctl(22, SG_IO, {interface_id='S', dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, cmdp="\x28\x00\x00\x12\x94\xdc\x00\x00\x02\x00", mx_sb_len=252, iovec_count=0, dxfer_len=4096, timeout=4294967295, flags=SG_FLAG_DIRECT_IO <unfinished ...>
+[etc]
+
+I suspect qemu is the culprit because I have tried a 4.19 guest kernel as well as a 5.9 one, with the same result.
\ No newline at end of file