Il mar 27 gen 2026, 19:47 Stefan Hajnoczi <[email protected]> ha scritto:
> Several of us have pondered a different approach that I will summarize > here. The <linux/pr.h> ioctl interface provides an alternative to > ioctl(SG_IO) without the CAP_SYS_RAWIO requirement. It supports both > SCSI and NVMe. Since privileges are not required, there would be no need > for the qemu-pr-helper daemon anymore. > Yes, no problem with that. It's easy to extend QEMU with a new pr-manager subclass that converts SCSI commands to PR ioctls. My suggestion is to implement <linux/pr.h> via upcalls from DM-Multipath > to multipathd. That way applications like QEMU can consistently use > <linux/pr.h> across block device types and no longer have to go through > the privileged libmpathpersist interface. > What do you have in mind for the upcall protocol? Does it need to be done with multipathd or can it be a separate daemon for privilege separation? I am not sure if there is any channel between dm-mpath and multipathd that can be extended (I think it only uses uevent?); maybe it would make sense to reuse qemu-pr-helper's protocol even. Paolo Once DM-Multipath support <linux/pr.h> is functional, the main QEMU > process can directly invoke the ioctls. qemu-pr-helper will no longer be > needed, eliminating privileged code and simplifying the setup required > by management tools such as libvirt and KubeVirt. > > The only loss in functionality that I have identified when switching to > <linux/pr.h> is that qemu-pr-helper supports SCSI TransportIDs for the > PERSISTENT RESERVATION OUT command. This is not supported by > <linux/pr.h>, but I'm not sure how this even works today since the guest > sees a virtual SCSI bus and is unaware of the physical bus or HBA. So > maybe that was never used in the first place? > > Does this plan sound good to you? > > Benjamin: I can work on the DM-Multipath upcalls if you are busy. > > Thanks, > Stefan >
