On Thu, 2025-05-15 at 10:29 -0400, Benjamin Marzinski wrote: > On Thu, May 15, 2025 at 12:34:13PM +0200, Martin Wilck wrote: > > > > However, I suppose that depends on the permissions with which the > > qemu > > process is started, no? Wouldn't qemu need CAP_SYS_RAWIO for PCI > > passthrough as well? > > > > I admit that I'm confused by the many indirections in qemu's scsi- > > block > > code flow. AFAICS qemu forwards everything except PRIN/PROUT to the > > kernel block device in "scsi-block" mode. Correct me if I'm wrong. > > > > Anwyway, let's not forget that we're talking about the kernel here. > > While qemu is the main target application for this feature is > > created, > > any application can use it, and it may or may not run with > > CAP_SYS_RAWIO. > > Maybe I'm missing your issue, but QEMU is just using DM's existing > ioctl > forwarding code, which was already designed for general use, and I > don't > see any capability issues with this patchset itself.
I didn't mean it this way. I was rather musing about the question whether doing SG_IO on multipath devices by forwarding them to the current path makes sense. Sorry for the confusing post. Regards Martin
