qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: qemu-devel@nongnu.org
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
	Peter Xu <peterx@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: [PATCH v1 13/13] migrate/ram: Tolerate partially changed mappings in postcopy code
Date: Wed, 19 Feb 2020 17:17:25 +0100	[thread overview]
Message-ID: <20200219161725.115218-14-david@redhat.com> (raw)
In-Reply-To: <20200219161725.115218-1-david@redhat.com>

When we partially change mappings (e.g., mmap over parts of an existing
mmap) where we have a userfaultfd handler registered, the handler will
implicitly be unregistered from the parts that changed. This is e.g., the
case when doing a qemu_ram_remap(), but is also a preparation for RAM
blocks with resizable allocations and we're shrinking RAM blocks.

When the mapping is changed and the handler is removed, any waiters are
woken up. Trying to place pages will fail. We can simply ignore erors
due to that when placing pages - as the mapping changed on the migration
destination, also the content is stale. E.g., after shrinking a RAM
block, nobody should be using that memory. After doing a
qemu_ram_remap(), the old memory is expected to have vanished.

Let's tolerate such errors (but still warn for now) when placing pages.
Also, add a comment why unregistering will continue to work even though
the mapping might have changed.

Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Juan Quintela <quintela@redhat.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
 migration/postcopy-ram.c | 43 ++++++++++++++++++++++++++++++++++------
 1 file changed, 37 insertions(+), 6 deletions(-)

diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index c68caf4e42..df9d27c004 100644
--- a/migration/postcopy-ram.c
+++ b/migration/postcopy-ram.c
@@ -506,6 +506,13 @@ static int cleanup_range(RAMBlock *rb, void *opaque)
     range_struct.start = (uintptr_t)host_addr;
     range_struct.len = length;
 
+    /*
+     * In case the mapping was partially changed since we enabled userfault
+     * (esp. when whrinking RAM blocks and we have resizable allocations, or
+     * via qemu_ram_remap()), the userfaultfd handler was already removed for
+     * the mappings that changed. Unregistering will, however, still work and
+     * ignore mappings without a registered handler.
+     */
     if (ioctl(mis->userfault_fd, UFFDIO_UNREGISTER, &range_struct)) {
         error_report("%s: userfault unregister %s", __func__, strerror(errno));
 
@@ -1239,10 +1246,28 @@ int postcopy_place_page(MigrationIncomingState *mis, void *host, void *from,
      */
     if (qemu_ufd_copy_ioctl(mis->userfault_fd, host, from, pagesize, rb)) {
         int e = errno;
-        error_report("%s: %s copy host: %p from: %p (size: %zd)",
-                     __func__, strerror(e), host, from, pagesize);
 
-        return -e;
+        /*
+         * When the mapping gets partially changed before we try to place a page
+         * (esp. when whrinking RAM blocks and we have resizable allocations, or
+         * via qemu_ram_remap()), the userfaultfd handler will be removed and
+         * placing pages will fail. In that case, any waiter was already woken
+         * up when the mapping was changed. We can safely ignore this, as
+         * mappings that change once we're running on the destination imply
+         * that memory of these mappings vanishes. Let's still print a warning
+         * for now.
+         *
+         * Old kernels report EINVAL, new kernels report ENOENT.
+         */
+        if (e == ENOENT || e == EINVAL) {
+            warn_report("%s: %s copy host: %p from: %p (size: %zd)",
+                        __func__, strerror(e), host, from, pagesize);
+        } else {
+            error_report("%s: %s copy host: %p from: %p (size: %zd)",
+                         __func__, strerror(e), host, from, pagesize);
+
+            return -e;
+        }
     }
 
     trace_postcopy_place_page(host);
@@ -1266,10 +1291,16 @@ int postcopy_place_page_zero(MigrationIncomingState *mis, void *host,
     if (qemu_ram_is_uf_zeroable(rb)) {
         if (qemu_ufd_copy_ioctl(mis->userfault_fd, host, NULL, pagesize, rb)) {
             int e = errno;
-            error_report("%s: %s zero host: %p",
-                         __func__, strerror(e), host);
 
-            return -e;
+            /* See the comment in postcopy_place_page() */
+            if (e == ENOENT || e == EINVAL) {
+                warn_report("%s: %s zero host: %p", __func__, strerror(e),
+                            host);
+            } else {
+                error_report("%s: %s zero host: %p", __func__, strerror(e),
+                             host);
+                return -e;
+            }
         }
         return postcopy_notify_shared_wake(rb,
                                            qemu_ram_block_host_offset(rb,
-- 
2.24.1



  parent reply	other threads:[~2020-02-19 16:57 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19 16:17 [PATCH v1 00/13] migrate/ram: Fix resizing RAM blocks while migrating David Hildenbrand
2020-02-19 16:17 ` [PATCH v1 01/13] util: vfio-helpers: Factor out and fix processing of existing ram blocks David Hildenbrand
2020-02-19 20:48   ` Peter Xu
2020-02-19 16:17 ` [PATCH v1 02/13] stubs/ram-block: Remove stubs that are no longer needed David Hildenbrand
2020-02-19 20:48   ` Peter Xu
2020-02-19 16:17 ` [PATCH v1 03/13] numa: Teach ram block notifiers about resizeable ram blocks David Hildenbrand
2020-02-19 20:48   ` Peter Xu
2020-02-19 16:17 ` [PATCH v1 04/13] numa: Make all callbacks of ram block notifiers optional David Hildenbrand
2020-02-19 20:49   ` Peter Xu
2020-02-19 16:17 ` [PATCH v1 05/13] migrate/ram: Handle RAM block resizes during precopy David Hildenbrand
2020-02-20 15:16   ` David Hildenbrand
2020-02-20 20:17     ` Peter Xu
2020-02-21  9:18       ` David Hildenbrand
2020-02-21 10:10         ` David Hildenbrand
2020-02-21 10:19           ` David Hildenbrand
2020-02-21 16:35             ` Peter Xu
2020-02-21 15:14   ` Dr. David Alan Gilbert
2020-02-21 15:18     ` David Hildenbrand
2020-02-21 15:40       ` Dr. David Alan Gilbert
2020-02-21 15:46         ` David Hildenbrand
2020-02-19 16:17 ` [PATCH v1 06/13] migrate/ram: Discard new RAM when growing RAM blocks and the VM is stopped David Hildenbrand
2020-02-21  9:08   ` David Hildenbrand
2020-02-21 15:51     ` Dr. David Alan Gilbert
2020-02-21 15:53       ` David Hildenbrand
2020-02-19 16:17 ` [PATCH v1 07/13] migrate/ram: Get rid of "place_source" in ram_load_postcopy() David Hildenbrand
2020-02-19 20:47   ` Peter Xu
2020-02-19 20:55     ` Peter Xu
2020-02-20 13:22       ` David Hildenbrand
2020-02-20 13:48         ` Peter Xu
2020-02-20  9:24     ` David Hildenbrand
2020-02-20 18:58       ` Dr. David Alan Gilbert
2020-02-19 16:17 ` [PATCH v1 08/13] migrate/ram: Simplify host page handling " David Hildenbrand
2020-02-19 16:17 ` [PATCH v1 09/13] migrate/ram: Consolidate variable reset after placement " David Hildenbrand
2020-02-19 16:17 ` [PATCH v1 10/13] migrate/ram: Handle RAM block resizes during postcopy David Hildenbrand
2020-02-20 20:54   ` Peter Xu
2020-02-21  8:35     ` David Hildenbrand
2020-02-21  8:41       ` David Hildenbrand
2020-02-19 16:17 ` [PATCH v1 11/13] migrate/multifd: Print used_length of memory block David Hildenbrand
2020-02-19 16:17 ` [PATCH v1 12/13] migrate/ram: Use offset_in_ramblock() in range checks David Hildenbrand
2020-02-19 16:17 ` David Hildenbrand [this message]
2020-02-20 11:24   ` [PATCH v1 13/13] migrate/ram: Tolerate partially changed mappings in postcopy code David Hildenbrand
2020-02-20 21:07     ` Peter Xu
2020-02-21  8:48       ` David Hildenbrand
2020-02-21 12:13 ` [PATCH v1 00/13] migrate/ram: Fix resizing RAM blocks while migrating 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=20200219161725.115218-14-david@redhat.com \
    --to=david@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=rth@twiddle.net \
    /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).