Am 13.05.2025 um 07:55 hat Christoph Hellwig geschrieben: > On Mon, May 12, 2025 at 05:18:43PM +0200, Kevin Wolf wrote: > > Yes, it's a bit unfortunate, but we have to work with what we have. QEMU > > doesn't even necessarily know that it's dealing with a multipath device, > > so it just has to blindly try the ioctl and see if it works. > > Why is qemu even using SG_IO to start with?
How else would you do SCSI passthrough? Ok, from your replies to Hannes I understand an implicit message, you wouldn't. But I don't think that's really an answer, at least not for all users. Yes, I'll give you that in the long term, we might be able to move some passthrough users away from it by using more specific interfaces like for persistent reservations (though see below). But for example, it's also used for vendor-specific commands and I don't see how Linux could ever provide more specific interfaces than SG_IO for those. But it's even about more than just accessing commands that aren't otherwise accessible. Mapping a SCSI response from the device to a single errno and back into SCSI status for the guest isn't lossless. 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. 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
