Re: Moving from qemu-pr-helper and libmpathpersist to <linux/pr.h>

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2850 bytes --]

On Wed, Jan 28, 2026 at 04:30:51PM +0100, Hannes Reinecke wrote:
> On 1/28/26 15:18, Stefan Hajnoczi wrote:
> > On Tue, Jan 27, 2026 at 08:45:39PM +0100, Paolo Bonzini wrote:
> > > Il mar 27 gen 2026, 19:47 Stefan Hajnoczi <stefanha@redhat.com> 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.
> > 
> > Yes. It will be possible to go further than that in the future:
> > 
> > Alberto has been working on QEMU block layer API support for persistent
> > reservations. When that becomes available, SCSI command parsing can
> > happen entirely within hw/scsi/scsi-disk.c for scsi-block and scsi-disk.
> > file-posix.c will then implement the new BlockDriver PR APIs via
> > <linux/pr.h> ioctls and other block drivers can implement them in
> > protocol-specific ways (e.g. iSCSI).
> > 
> > > 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.
> > 
> > I don't have a strong opinion on the protocol. My thought was to do a
> > traditional upcall with call_usermodehelper() with an execve argv/envp
> > protocol. That way there is no need to register a file descriptor. The
> > downside is that this approach is less efficient and more likely to fail
> > when the host is under memory pressure, but PR operations are not that
> > frequent.
> > 
> gnaa. call_usermodehelper() is _evil_. It might be executed with any
> arbitrary fs context, and you better hope the executable is present
> there ...
> 
> Maybe look at the handshake daemon. That's solving a very similar issue
> which we had for TLS.

Netlink is the most complex approach. I had a hard to understanding what
was going from looking at drivers/nvme/host/ and net/handshake/. But if
netlink is the way to do this, I'm sure it can be done.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]