From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: "Michal Prívozník" <mprivozn@redhat.com>
Cc: Peter Xu <peterx@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 14:15:11 +0000 [thread overview]
Message-ID: <Y9KK72k8dZU7Ccau@work-vm> (raw)
In-Reply-To: <0f8ad497-202d-ae55-e468-77bb726a2699@redhat.com>
* 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?
Dave
> Michal
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2023-01-26 14:16 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 [this message]
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
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=Y9KK72k8dZU7Ccau@work-vm \
--to=dgilbert@redhat.com \
--cc=lsoaresp@redhat.com \
--cc=mprivozn@redhat.com \
--cc=peterx@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).