qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: lma <lma@suse.de>
Cc: quintela@redhat.com, qemu-devel@nongnu.org, dgilbert@redhat.com
Subject: Re: [PATCH 0/3] Postcopy migration: Add userfaultfd- user-mode-only capability
Date: Fri, 15 Oct 2021 16:28:39 +0800	[thread overview]
Message-ID: <YWk7t8Za3l4bhGIB@t490s> (raw)
In-Reply-To: <b17650b7db7bece420f8f1ad2aaa651a@suse.de>

On Fri, Oct 15, 2021 at 04:16:15PM +0800, lma wrote:
> 在 2021-10-15 14:12,Peter Xu 写道:
> > On Fri, Oct 15, 2021 at 01:38:06PM +0800, lma wrote:
> > > 在 2021-10-15 07:43,Peter Xu 写道:
> > > > On Thu, Oct 14, 2021 at 05:15:48PM +0800, Lin Ma wrote:
> > > > > Since kernel v5.11, Unprivileged user (without SYS_CAP_PTRACE
> > > > > capability)
> > > > > must pass UFFD_USER_MODE_ONLY to userfaultd in case
> > > > > unprivileged_userfaultfd
> > > > > sysctl knob is 0.
> > > > > Please refer to https://lwn.net/Articles/819834/ and the kernel
> > > > > commits:
> > > > > 37cd0575 userfaultfd: add UFFD_USER_MODE_ONLY
> > > > > d0d4730a userfaultfd: add user-mode only option to
> > > > > unprivileged_userfaultfd sysctl knob
> > > > >
> > > > > This patch set adds a migration capability to pass UFFD_USER_MODE_ONLY
> > > > > for postcopy migration.
> > > >
> > > > Then it's at least no KVM, no vhost, am I right?  Could I ask is there a
> > > > real
> > > > user behind this?  Thanks,
> > > 
> > > Well, The "user-mode-only" has nothing to do with qemu's user-mode
> > > emulation.
> > 
> > I didn't follow why you thought my question was about "user-mode
> > emulation"..
> Sorry about the misunderstanding.

No worry. :)

> 
> > To ask in another way: after this new cap set, qemu will get a SIGBUS
> > and VM
> > will crash during postcopy migrating as long as either KVM or
> > vhost-kernel
> > faulted on any of the missing pages, am I right?
> 
> Oops...Yes, you're right. It indeed casues qemu crash on destination due to
> fault on missing pages.
> This patch set and my thought about introducing this cap to qemu are wrong.

I can't say it's wrong, it's just that it may need some more thoughts on how to
make it applicable.

We'll need to make sure no kernel module will access guest pages, however I
think it'll be so hard to guarantee.  For example, there can be some read()
syscall from qemu initiated with guest pages passed in as the buffer (so the
kernel will fill up the buffer when syscall returns), then if that page is
missing on dst then that'll also trigger a kernel page fault and it'll crash
qemu too even if no kvm/vhost-kernel is used.  We'll need to dig out everything
like that.

The other thing is about my original question on whether it'll be useful in any
way, and I just worry it won't help anyone, because afaiu any real user of
migration (I believe it's majorly public/private cloud) will definitely at
least be kvm based as tcg could be too slow.  Then they'll simply enable the
unprivileged uffd on the hosts, since even if it's unsafe it'll be at least as
unsafe as before unprivileged_userfaultfd is introduced.

Thanks,

-- 
Peter Xu



  reply	other threads:[~2021-10-15  9:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-14  9:15 [PATCH 0/3] Postcopy migration: Add userfaultfd- user-mode-only capability Lin Ma
2021-10-14  9:15 ` [PATCH 1/3] migration: introduce postcopy-uffd-usermode-only capability Lin Ma
2021-10-14  9:15 ` [PATCH 2/3] migration: postcopy-uffd-usermode-only documentation Lin Ma
2021-10-14  9:15 ` [PATCH 3/3] tests: add postcopy-uffd-usermode-only capability into migration-test Lin Ma
2021-10-14 23:43 ` [PATCH 0/3] Postcopy migration: Add userfaultfd- user-mode-only capability Peter Xu
2021-10-15  5:38   ` lma
2021-10-15  6:12     ` Peter Xu
2021-10-15  8:16       ` lma
2021-10-15  8:28         ` Peter Xu [this message]
2021-10-15  9:49           ` lma

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=YWk7t8Za3l4bhGIB@t490s \
    --to=peterx@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=lma@suse.de \
    --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).