1 files changed, 21 insertions, 0 deletions
diff --git a/results/classifier/accel-gemma3:12b/kvm/1859378 b/results/classifier/accel-gemma3:12b/kvm/1859378
new file mode 100644
index 00000000..785a3093
--- /dev/null
+++ b/results/classifier/accel-gemma3:12b/kvm/1859378
@@ -0,0 +1,21 @@
+
+xhci Control Transfer requiring a Status TRB before starting transfer
+
+This may not necessarily be a bug, but more of a change.
+
+A little background may need to be in order.
+
+With all USB Control transfers, there is a SETUP transfer, zero or more DATA transfers, and if successful, a STATUS transfer.  This STATUS transfer is used to indicate to the recipient that the previous transfers were successful.  For example, in a CONTROL IN transfer, the host sends a SETUP packet to the device, receives zero or more DATA packets, and then on successful transfer, the HOST sends the STATUS packet indicating to the device that all was received.
+
+If no DATA packets are received, the HOST is not to send a STATUS packet.  This could be due to a STALL or other error.
+
+With this in mind, the STATUS transfer, in this case an xHCI STATUS TRB, may not even be on the transfer ring yet.  The HOST software may be waiting for a successful transfer before it submits the STATUS transfer.
+
+However, if you look at the test at line 1701 (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c#l1701), the current code will not start the CONTROL transfer at all if it doesn't see that STATUS TRB on the ring.
+
+In my opinion, this is in error.  It is not required that a STATUS TRB be on the ring to start the CONTROL transfer.  This STATUS TRB can be placed on the ring after a successful SETUP and zero or more DATA transfers followed by a ring to the door bell.  Then after a successful transfer to this point, placing this STATUS TRB on the ring and another ring to the door bell.
+
+In my opinion, the check at line 1701 should be removed.
+
+Thank you,
+Ben
\ No newline at end of file