All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Martin Wilck <mwilck@suse.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
	Benjamin Marzinski <bmarzins@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-block@nongnu.org, Kevin Wolf <kwolf@redhat.com>,
	Hannes Reinecke <hare@suse.de>,
	afaria@redhat.com, qemu-devel@nongnu.org,
	Mikulas Patocka <mpatocka@redhat.com>
Subject: Re: Moving from qemu-pr-helper and libmpathpersist to <linux/pr.h>
Date: Thu, 5 Feb 2026 12:01:13 +0000	[thread overview]
Message-ID: <aYSGia2Zy_g5iop5@redhat.com> (raw)
In-Reply-To: <d6cfd9a22c397e3811eaa73409f4ab1499e3e63f.camel@suse.com>

On Thu, Feb 05, 2026 at 12:52:33PM +0100, Martin Wilck wrote:
> On Wed, 2026-02-04 at 13:32 -0500, Stefan Hajnoczi wrote:
> > On Wed, Feb 04, 2026 at 02:19:48PM +0100, Martin Wilck wrote:
> > > Hi Stefan,
> > > 
> > > So the ioctls will pass through qemu into the kernel, to be
> > > intercepted
> > > by the dm-mpath driver, which will use an upcall to have them
> > > handled
> > > by mpathpersistd (for the actual command) and multipathd (for the
> > > path
> > > registrations).
> > > 
> > > I don't fully understand the advantage, security and complexity-
> > > wise,
> > > of this concept, compared to intercepting them qemu and using a
> > > socket
> > > to talk to mpathpersistd directly. If we did this, we could even
> > > support both generic and SCSI PR commands.
> > 
> > Hi Martin,
> > The simplification and security benefits are on the application side,
> > not on the DM-Multipath side, so I can see what you're getting at.
> > From
> > the DM-Multipath perspective things get a little more complex.
> > 
> > From an application perspective, a single API that works across block
> > device types (SCSI, NVMe, DM-Multipath) and requires no privileges or
> > sockets (they are a pain in container environments) is the most
> > convenient. The <linux/pr.h> ioctl API offers exactly this.
> 
> I may be missing something, but AFAICS the PR ioctls require having a
> block device open for writing, which does either require root
> privileges, or some file descriptor previously opened with privileges
> and forwarded to another, less privileged process. No?

While QEMU is run unprivileged, libvirt will grant QEMU access any block
devices that have been configured for the guest in question. On Linux,
libvirt will create a new /dev tmpfs populated with the allow-list of
device nodes the guest is permitted to access, with suitable file
permissions, ownership & SELinux labels set.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2026-02-05 12:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-27 18:47 Moving from qemu-pr-helper and libmpathpersist to <linux/pr.h> Stefan Hajnoczi
2026-01-27 19:45 ` Paolo Bonzini
2026-01-28 14:18   ` Stefan Hajnoczi
2026-01-28 15:30     ` Hannes Reinecke
2026-01-28 16:13       ` Stefan Hajnoczi
2026-01-27 21:06 ` Benjamin Marzinski
2026-02-03 15:09   ` Stefan Hajnoczi
2026-02-03 17:53     ` Benjamin Marzinski
2026-02-03 18:04       ` Stefan Hajnoczi
2026-02-04 13:19         ` Martin Wilck
2026-02-04 18:32           ` Stefan Hajnoczi
2026-02-04 23:57             ` Hannes Reinecke
2026-02-05  1:03               ` Benjamin Marzinski
2026-02-05 10:20                 ` Martin Wilck
2026-02-05 11:52             ` Martin Wilck
2026-02-05 12:01               ` Daniel P. Berrangé [this message]
2026-02-05 13:39                 ` Stefan Hajnoczi
2026-02-06  0:03                   ` Hannes Reinecke
2026-02-06 14:08                     ` Stefan Hajnoczi
2026-02-09 12:50                       ` Hannes Reinecke
2026-02-09 14:23                         ` Stefan Hajnoczi
2026-02-10 10:23                           ` Martin Wilck
2026-02-10 13:59                             ` Stefan Hajnoczi
2026-02-10 14:29                               ` Martin Wilck
2026-02-05 14:28               ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aYSGia2Zy_g5iop5@redhat.com \
    --to=berrange@redhat.com \
    --cc=afaria@redhat.com \
    --cc=bmarzins@redhat.com \
    --cc=hare@suse.de \
    --cc=kwolf@redhat.com \
    --cc=mpatocka@redhat.com \
    --cc=mwilck@suse.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.