From: Peter Xu <peterx@redhat.com>
To: Andrey Gruzdev <andrey.gruzdev@virtuozzo.com>
Cc: Juan Quintela <quintela@redhat.com>,
David Hildenbrand <david@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Alexander Duyck <alexander.duyck@gmail.com>,
qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
Den Lunev <den@openvz.org>, Paolo Bonzini <pbonzini@redhat.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH v13 0/5] UFFD write-tracking migration/snapshots
Date: Fri, 19 Feb 2021 15:50:52 -0500 [thread overview]
Message-ID: <20210219205052.GK6669@xz-x1> (raw)
In-Reply-To: <add9a7f7-9e02-5024-4bfd-2597a8920ec5@virtuozzo.com>
Andrey,
On Fri, Feb 19, 2021 at 09:57:37AM +0300, Andrey Gruzdev wrote:
> For the discards that happen before snapshot is started, I need to dig into Linux and QEMU virtio-baloon
> code more to get clear with it.
Yes it's very tricky on how the error could trigger.
Let's think of below sequence:
- Start a guest with init_on_free=1 set and also a virtio-balloon device
- Guest frees a page P and zeroed it (since init_on_free=1). Now P contains
all zeros.
- Virtio-balloon reports this page to host, MADV_DONTNEED sent, then this
page is dropped on the host.
- Start live snapshot, wr-protect all pages (but not including page P because
it's currently missing). Let's call it $SNAPSHOT1.
- Guest does alloc_page(__GFP_ZERO), accidentally fetching this page P and
returned
- So far, page P is still all zero (which is good!), then guest uses page P
and writes data to it (say, now P has data P1 rather than all zeros).
- Live snapshot saves page P, which content P1 rather than all zeros.
- Live snapshot completed. Saved as $SNAPSHOT1.
Then when load snapshot $SNAPSHOT1, we'll have P contains data P1. After
snapshot loaded, when guest allocate again with alloc_page(__GFP_ZERO) on this
page P, since guest kernel "thought" this page is all-zero already so memzero()
is skipped even if __GFP_ZERO is provided. Then this page P (with content P1)
got returned for the alloc_page(__GFP_ZERO) even if __GFP_ZERO set. That could
break the caller of alloc_page().
> Anyhow I'm quite sure that adding global MISSING handler for snapshotting
> is too heavy and not really needed.
UFFDIO_ZEROCOPY installs a zero pfn and that should be all of it. There'll
definitely be overhead, but it may not be that huge as imagined. Live snapshot
is great in that we have point-in-time image of guest without stopping the
guest, so taking slightly longer time won't be a huge loss to us too.
Actually we can also think of other ways to work around it. One way is we can
pre-fault all guest pages before wr-protect. Note that we don't need to write
to the guest page because read would suffice, since uffd-wp would also work
with zero pfn. It's just that this workaround won't help on saving snapshot
disk space, but it seems working. It would be great if you have other
workarounds, maybe as you said UFFDIO_ZEROCOPY is not the only route.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2021-02-19 20:51 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-21 15:24 [PATCH v13 0/5] UFFD write-tracking migration/snapshots andrey.gruzdev--- via
2021-01-21 15:24 ` [PATCH v13 1/5] migration: introduce 'background-snapshot' migration capability andrey.gruzdev--- via
2021-01-21 15:24 ` [PATCH v13 2/5] migration: introduce UFFD-WP low-level interface helpers andrey.gruzdev--- via
2021-01-21 15:24 ` [PATCH v13 3/5] migration: support UFFD write fault processing in ram_save_iterate() andrey.gruzdev--- via
2021-01-21 15:24 ` [PATCH v13 4/5] migration: implementation of background snapshot thread andrey.gruzdev--- via
2021-01-28 18:29 ` Dr. David Alan Gilbert
2021-01-29 8:17 ` Andrey Gruzdev
2021-01-21 15:24 ` [PATCH v13 5/5] migration: introduce 'userfaultfd-wrlat.py' script andrey.gruzdev--- via
2021-02-09 12:37 ` [PATCH v13 0/5] UFFD write-tracking migration/snapshots David Hildenbrand
2021-02-09 18:38 ` Andrey Gruzdev
2021-02-09 19:06 ` David Hildenbrand
2021-02-09 20:09 ` Peter Xu
2021-02-09 20:31 ` Peter Xu
2021-02-11 9:21 ` Andrey Gruzdev
2021-02-11 17:18 ` Peter Xu
2021-02-11 18:15 ` Andrey Gruzdev
2021-02-11 16:19 ` Andrey Gruzdev
2021-02-11 17:32 ` Peter Xu
2021-02-11 18:28 ` Andrey Gruzdev
2021-02-11 19:01 ` David Hildenbrand
2021-02-11 20:31 ` Peter Xu
2021-02-11 20:44 ` David Hildenbrand
2021-02-11 21:05 ` Peter Xu
2021-02-11 21:09 ` David Hildenbrand
2021-02-12 3:06 ` Peter Xu
2021-02-12 8:52 ` David Hildenbrand
2021-02-12 16:11 ` Peter Xu
2021-02-13 9:34 ` Andrey Gruzdev
2021-02-13 10:30 ` David Hildenbrand
2021-02-16 23:35 ` Peter Xu
2021-02-17 10:31 ` David Hildenbrand
2021-02-19 6:57 ` Andrey Gruzdev
2021-02-19 7:45 ` David Hildenbrand
2021-02-19 20:50 ` Peter Xu [this message]
2021-02-19 21:10 ` Peter Xu
2021-02-19 21:14 ` David Hildenbrand
2021-02-19 21:20 ` David Hildenbrand
2021-02-19 22:47 ` Peter Xu
2021-02-20 7:59 ` David Hildenbrand
2021-02-22 17:29 ` Peter Xu
2021-02-22 17:33 ` David Hildenbrand
2021-02-22 17:54 ` Peter Xu
2021-02-22 18:11 ` David Hildenbrand
2021-02-24 16:56 ` Andrey Gruzdev
2021-02-24 17:01 ` David Hildenbrand
2021-02-24 17:52 ` Andrey Gruzdev
2021-02-24 16:43 ` Andrey Gruzdev
2021-02-24 16:54 ` David Hildenbrand
2021-02-24 17:00 ` Andrey Gruzdev
2021-02-11 19:21 ` David Hildenbrand
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=20210219205052.GK6669@xz-x1 \
--to=peterx@redhat.com \
--cc=alexander.duyck@gmail.com \
--cc=andrey.gruzdev@virtuozzo.com \
--cc=armbru@redhat.com \
--cc=david@redhat.com \
--cc=den@openvz.org \
--cc=dgilbert@redhat.com \
--cc=mst@redhat.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 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).