Il mar 13 mag 2025, 11:29 Kevin Wolf <kw...@redhat.com> ha scritto: > QEMU's scsi-block device actually started off using normal I/O for reads > and writes and using SG_IO only for things that aren't covered by normal > I/O. But then those had to be changed to SG_IO, too, so that the guest > would actually see the full SCSI status. Things the commit message > mentions are unit attention codes and handling RESERVATION CONFLICT > correctly (which made me unsure above if the more specific interface for > reservations could actually be used to fully get rid of SG_IO). For more > context, I'm adding Paolo who actually made that change back then. He > may remember the concrete bug(s) this fixed.
The original reason to avoid SG_IO for reads and writes was purely performance (using the host scheduler), but it turned out to be a bad idea. RESERVATION CONFLICT indeed was one of the reasons why I moved QEMU away from SG_IO. It has since been fixed, because these days Linux uses EBADE for it and likewise there are errno values for some other statuses or sense codes, but it helps more in general to have the precise SCSI status and sense data. Having the real status and sense for example lets QEMU decide which errors to pass to the guest and which should be handled in the host (for example by pausing the VM). Some HBAs also have equivalents of Linux's host_status, and passing that down also makes for more accurate pass through. Also, specifically for reservations, I also didn't like the idea that a guest command could be split in multiple host commands and the reservation conflict would appear in the middle due to a concurrent PR OUT command. To be honest I don't know how physical disks and controllers handle that, but I didn't want to make it worse. Thanks, Paolo > So if you want the guest device to behave mostly the same as your host > device, I don't really see any way around SCSI passthrough and therefore > SG_IO. > > Kevin >
