From: Peter Xu <peterx@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Denis Plotnikov <dplotnikov@virtuozzo.com>,
qemu-devel@nongnu.org, quintela@redhat.com
Subject: Re: [Qemu-devel] [PATCH v0 0/7] Background snapshots
Date: Thu, 26 Jul 2018 17:23:07 +0800 [thread overview]
Message-ID: <20180726092307.GL2479@xz-mi> (raw)
In-Reply-To: <e1c85e53-1b94-b1df-b7ee-6d93bb43caf6@redhat.com>
On Thu, Jul 26, 2018 at 10:51:33AM +0200, Paolo Bonzini wrote:
> On 25/07/2018 22:04, Andrea Arcangeli wrote:
> >
> > It may look like the uffd-wp model is wish-feature similar to an
> > optimization, but without the uffd-wp model when the WP fault is
> > triggered by kernel code, the sigsegv model falls apart and requires
> > all kind of ad-hoc changes just for this single feature. Plus uffd-wp
> > has other benefits: it makes it all reliable in terms of not
> > increasing the number of vmas in use during the snapshot. Finally it
> > makes it faster too with no mmap_sem for reading and no sigsegv
> > signals.
> >
> > The non cooperative features got merged first because there was much
> > activity on the kernel side on that front, but this is just an ideal
> > time to nail down the remaining issues in uffd-wp I think. That I
> > believe is time better spent than trying to emulate it with sigsegv
> > and changing all drivers to send new events down to qemu specific to
> > the sigsegv handling. We considered this before doing uffd for
> > postcopy too but overall it's unreliable and more work (no single
> > change was then needed to KVM code with uffd to handle postcopy and
> > here it should be the same).
>
> I totally agree. The hard part in userfaultfd was the changes to the
> kernel get_user_pages API, but the payback was huge because _all_ kernel
> uses (KVM, vhost-net, syscalls, etc.) just work with userfaultfd. Going
> back to mprotect would be a huge mistake.
Thanks for explaining the bits. I'd say I wasn't aware of the
difference before I started the investigation (and only until now I
noticed that major difference between mprotect and userfaultfd). I'm
really glad that it's much clear (at least for me) on which way we
should choose.
Now I'm thinking whether we can move the userfault write protect work
forward. The latest discussion I saw so far is in 2016, when someone
from Huawei tried to use the write protect feature for that old
version of live snapshot but reported issue:
https://lists.gnu.org/archive/html/qemu-devel/2016-12/msg01127.html
Is that the latest status for userfaultfd wr-protect?
If so, I'm thinking whether I can try to re-verify the work (I tried
his QEMU repository but I failed to compile somehow, so I plan to
write some even simpler code to try) to see whether I can get the same
KVM error he encountered.
Thoughts?
Regards,
--
Peter Xu
next prev parent reply other threads:[~2018-07-26 9:23 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-29 8:03 [Qemu-devel] [PATCH v0 0/7] Background snapshots Denis Plotnikov
2018-06-29 8:03 ` [Qemu-devel] [PATCH v0 1/7] migration: add background snapshot capability Denis Plotnikov
2018-06-29 16:02 ` Eric Blake
2018-07-12 9:03 ` Dr. David Alan Gilbert
2018-06-29 8:03 ` [Qemu-devel] [PATCH v0 2/7] bitops: add some atomic versions of bitmap operations Denis Plotnikov
2018-07-12 9:21 ` Dr. David Alan Gilbert
2018-06-29 8:03 ` [Qemu-devel] [PATCH v0 3/7] threads: add infrastructure to process sigsegv Denis Plotnikov
2018-07-12 9:53 ` Dr. David Alan Gilbert
2018-06-29 8:03 ` [Qemu-devel] [PATCH v0 4/7] migration: add background snapshot infrastructure Denis Plotnikov
2018-07-12 11:46 ` Dr. David Alan Gilbert
2018-06-29 8:03 ` [Qemu-devel] [PATCH v0 5/7] kvm: add failed memeory access exit reason Denis Plotnikov
2018-06-29 8:03 ` [Qemu-devel] [PATCH v0 6/7] kvm: add vCPU failed memeory access processing Denis Plotnikov
2018-06-29 8:03 ` [Qemu-devel] [PATCH v0 7/7] migration: add background snapshotting Denis Plotnikov
2018-07-12 18:59 ` Dr. David Alan Gilbert
2018-06-29 11:53 ` [Qemu-devel] [PATCH v0 0/7] Background snapshots Dr. David Alan Gilbert
2018-07-25 10:18 ` Peter Xu
2018-07-25 19:17 ` Dr. David Alan Gilbert
2018-07-25 20:04 ` Andrea Arcangeli
2018-07-26 8:51 ` Paolo Bonzini
2018-07-26 9:23 ` Peter Xu [this message]
2018-08-13 12:55 ` Denis Plotnikov
2018-08-13 19:00 ` Dr. David Alan Gilbert
2018-08-14 5:45 ` Peter Xu
2018-08-14 6:13 ` Mike Rapoport
2018-08-14 23:16 ` Mike Kravetz
2018-07-26 15:13 ` Dr. David Alan Gilbert
2018-07-02 11:23 ` Peter Xu
2018-07-02 12:40 ` Denis Plotnikov
2018-07-03 5:54 ` Peter Xu
2018-07-13 5:20 ` Peter Xu
2018-07-16 15:00 ` Denis Plotnikov
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=20180726092307.GL2479@xz-mi \
--to=peterx@redhat.com \
--cc=aarcange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=dplotnikov@virtuozzo.com \
--cc=pbonzini@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 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.