On Thu, 2025-05-15 at 23:00 -0700, Christoph Hellwig wrote: > On Thu, May 15, 2025 at 12:11:49PM +0200, Kevin Wolf wrote: > > If you're talking about SG_IO in dm-mpath, then PRIN/PROUT commands > > are > > actually the one thing that we don't need. libmpathpersist sends > > the > > commands to the individual path devices, so dm-mpath will never see > > those. It's mostly about getting the full results on the SCSI level > > for > > normal I/O commands. > > > > There has actually been a patch series on qemu-devel last year > > (that I > > haven't found the time to review properly yet) that would add > > explicit > > persistent reservation operations to QEMU's block layer that could > > then > > be used with the emulated scsi-hd device. On the backend, it only > > implemented it for iscsi, but I suppose we could implement it for > > file-posix, too (using the same libmpathpersist code as for > > passthrough). If that works, maybe at least some users can move > > away > > from SCSI passthrough. > x > Please call into the kernel PR code instead of hacking up more of > this, which will just run into problems again.
I still don't get what this buys us. The guest (which might be Windows or whatever else) sends SCSI reservation commands. qemu will have to intercept these anyway, unless the backend device is a plain SCSI device (in which case transformation into generic PR command would be a strange thing to do). If the backend device is multipath on SCSI, qemu-pr-helper would take the most appropriate action and return the most appropriate result code. The dm-multipath layer can't do it as well, as it doesn't have the full information about the target that's available in user space (see Ben's note about ALL_TG_PT for example). I don't see any benefit from using a generic reservation on dm-mpath instead of using qemu-pr- helper for this important use case. I also don't see why this way of handling SCSI PR commands would be dangerous. You are of course right to say that passthrough of other SCSI commands (except regular IO and PR) is highly dangerous, but in the concept that Kevin described that wouldn't happen. Transforming the SCSI reservation commands into generic reservation commands makes sense for _other_ types of backend devices. NVMe comes to mind, but (for real-world applications) not much else. (But does it make sense to present NVMe devices to guests as SCSI devices?). Regards Martin
