qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Michal Prívozník" <mprivozn@redhat.com>,
	qemu-devel@nongnu.org,
	"Leonardo Bras Soares Passos" <lsoaresp@redhat.com>,
	"Juan Quintela" <quintela@redhat.com>
Subject: Re: [PATCH 0/3] util/userfaultfd: Support /dev/userfaultfd
Date: Thu, 26 Jan 2023 12:26:45 -0500	[thread overview]
Message-ID: <Y9K31a04dTChnaOV@x1n> (raw)
In-Reply-To: <Y9KjZeu9t37XyZ3q@redhat.com>

On Thu, Jan 26, 2023 at 03:59:33PM +0000, Daniel P. Berrangé wrote:
> On Thu, Jan 26, 2023 at 10:25:05AM -0500, Peter Xu wrote:
> > On Thu, Jan 26, 2023 at 02:15:11PM +0000, Dr. David Alan Gilbert wrote:
> > > * Michal Prívozník (mprivozn@redhat.com) wrote:
> > > > On 1/25/23 23:40, Peter Xu wrote:
> > > > > The new /dev/userfaultfd handle is superior to the system call with a
> > > > > better permission control and also works for a restricted seccomp
> > > > > environment.
> > > > > 
> > > > > The new device was only introduced in v6.1 so we need a header update.
> > > > > 
> > > > > Please have a look, thanks.
> > > > 
> > > > I was wondering whether it would make sense/be possible for mgmt app
> > > > (libvirt) to pass FD for /dev/userfaultfd instead of QEMU opening it
> > > > itself. But looking into the code, libvirt would need to do that when
> > > > spawning QEMU because that's when QEMU itself initializes internal state
> > > > and queries userfaultfd caps.
> > > 
> > > You also have to be careful about what the userfaultfd semantics are; I
> > > can't remember them - but if you open it in one process and pass it to
> > > another process, which processes address space are you trying to
> > > monitor?
> > 
> > Yes it's a problem.  The kernel always fetches the current mm_struct* which
> > represents the current context of virtual address space when creating the
> > uffd handle (for either the syscall or the ioctl() approach).
> 
> At what point does the process address space get associated ? When
> the /dev/userfaultfd is opened, or only when ioctl(USERFAULTFD_IOC_NEW)
> is called ?  If it is the former, then we have no choice, QEMU must open
> it. if it is the latter, then libvirt can open /dev/userfaultfd, pass
> it to QEMU which can then do the ioctl(USERFAULTFD_IOC_NEW).

Good point.. It should be the latter, so should be doable.

What should be the best interface for QEMU to detect the fd passing over to
it?  IIUC qemu_open() requires the name to be /dev/fdset/*, but there's no
existing cmdline that QEMU can know which fd number to fetch from fdset to
be used as the /dev/userfaultfd descriptor.

monitor_get_fd() seems more proper, where we can define an unique string so
Libvirt can preset the descriptor with the same string attached to it, then
I can opt-in monitor_get_fd() before trying to open() or doing the syscall.

Thanks,

-- 
Peter Xu



  reply	other threads:[~2023-01-26 17:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-25 22:40 [PATCH 0/3] util/userfaultfd: Support /dev/userfaultfd Peter Xu
2023-01-25 22:40 ` [PATCH 1/3] linux-headers: Update to v6.1 Peter Xu
2023-01-25 22:40 ` [PATCH 2/3] util/userfaultfd: Add uffd_open() Peter Xu
2023-01-25 23:04   ` Philippe Mathieu-Daudé
2023-01-26 15:58     ` Peter Xu
2023-01-25 22:40 ` [PATCH 3/3] util/userfaultfd: Support /dev/userfaultfd Peter Xu
2023-01-25 23:08   ` Philippe Mathieu-Daudé
2023-01-26 17:33     ` Peter Xu
2023-01-26  9:02   ` Daniel P. Berrangé
2023-01-26  9:05     ` Daniel P. Berrangé
2023-01-26 20:03       ` Peter Xu
2023-01-26 14:13 ` [PATCH 0/3] " Michal Prívozník
2023-01-26 14:15   ` Dr. David Alan Gilbert
2023-01-26 15:25     ` Peter Xu
2023-01-26 15:29       ` Michal Prívozník
2023-01-26 15:49         ` Peter Xu
2023-01-26 15:59       ` Daniel P. Berrangé
2023-01-26 17:26         ` Peter Xu [this message]
2023-01-31 19:48           ` Peter Xu
2023-01-31 20:06             ` Daniel P. Berrangé
2023-01-31 21:01               ` Peter Xu
2023-02-01  7:55                 ` Michal Prívozník
2023-02-01 14:58                   ` Peter Xu

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=Y9K31a04dTChnaOV@x1n \
    --to=peterx@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=lsoaresp@redhat.com \
    --cc=mprivozn@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).