All of lore.kernel.org
 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 v3 13/13] migration/ram: Tolerate partially changed mappings in postcopy code
Date: Wed, 26 Feb 2020 16:53:04 +0100	[thread overview]
Message-ID: <20200226155304.60219-14-david@redhat.com> (raw)
In-Reply-To: <20200226155304.60219-1-david@redhat.com>

When we partially change mappings (esp., mmap over parts of an existing
mmap like qemu_ram_remap() does) where we have a userfaultfd handler
registered, the handler will implicitly be unregistered from the parts that
changed.

Trying to place pages onto mappings where there is no longer a handler
registered will fail. Let's make sure that any waiter is woken up - we
have to do that manually.

Let's also document how UFFDIO_UNREGISTER will handle this scenario.

This is mainly a preparation for RAM blocks with resizable allcoations,
where the mapping of the invalid RAM range will change. The source will
keep sending pages that are outside of the new (shrunk) RAM size. We have
to treat these pages like they would have been migrated, but can
essentially simply drop the content (ignore the placement error).

Keep printing a warning when we hit EINVAL, to avoid hiding other
(programming) issues. ENOENT is unique.

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 | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index c68caf4e42..f39c6304de 100644
--- a/migration/postcopy-ram.c
+++ b/migration/postcopy-ram.c
@@ -506,6 +506,14 @@ 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
+     * (e.g., 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. There could only be
+     * an issue if we would suddenly encounter a mapping that's incompatible
+     * with UFFD - which cannot happen within a single RAM block.
+     */
     if (ioctl(mis->userfault_fd, UFFDIO_UNREGISTER, &range_struct)) {
         error_report("%s: userfault unregister %s", __func__, strerror(errno));
 
@@ -1180,6 +1188,17 @@ int postcopy_ram_incoming_setup(MigrationIncomingState *mis)
     return 0;
 }
 
+static int qemu_ufd_wake_ioctl(int userfault_fd, void *host_addr,
+                               uint64_t pagesize)
+{
+    struct uffdio_range range = {
+        .start = (uint64_t)(uintptr_t)host_addr,
+        .len = pagesize,
+    };
+
+    return ioctl(userfault_fd, UFFDIO_WAKE, &range);
+}
+
 static int qemu_ufd_copy_ioctl(int userfault_fd, void *host_addr,
                                void *from_addr, uint64_t pagesize, RAMBlock *rb)
 {
@@ -1198,6 +1217,26 @@ static int qemu_ufd_copy_ioctl(int userfault_fd, void *host_addr,
         zero_struct.mode = 0;
         ret = ioctl(userfault_fd, UFFDIO_ZEROPAGE, &zero_struct);
     }
+
+    /*
+     * When the mapping gets partially changed (e.g., qemu_ram_remap()) before
+     * we try to place a page, the userfaultfd handler will be removed for the
+     * changed mappings and placing pages will fail. We can safely ignore this,
+     * because mappings that changed on the destination don't need data from the
+     * source (e.g., qemu_ram_remap()). Wake up any waiter waiting for that page
+     * (unlikely but possible). Waking up waiters is always possible, even
+     * without a registered userfaultfd handler.
+     *
+     * Old kernels report EINVAL, new kernels report ENOENT in case there is
+     * no longer a userfaultfd handler for a mapping.
+     */
+    if (ret && (errno == ENOENT || errno == EINVAL)) {
+        if (errno == EINVAL) {
+            warn_report("%s: Failed to place page %p. Waking up any waiters.",
+                         __func__, host_addr);
+        }
+        ret = qemu_ufd_wake_ioctl(userfault_fd, host_addr, pagesize);
+    }
     if (!ret) {
         ramblock_recv_bitmap_set_range(rb, host_addr,
                                        pagesize / qemu_target_page_size());
-- 
2.24.1



  parent reply	other threads:[~2020-02-26 16:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26 15:52 [PATCH v3 00/13] migrate/ram: Fix resizing RAM blocks while migrating David Hildenbrand
2020-02-26 15:52 ` [PATCH v3 01/13] util: vfio-helpers: Factor out and fix processing of existing ram blocks David Hildenbrand
2020-02-26 15:52 ` [PATCH v3 02/13] stubs/ram-block: Remove stubs that are no longer needed David Hildenbrand
2020-02-26 15:52 ` [PATCH v3 03/13] numa: Teach ram block notifiers about resizeable ram blocks David Hildenbrand
2020-02-26 15:52   ` [Xen-devel] " David Hildenbrand
2020-02-26 15:52 ` [PATCH v3 04/13] numa: Make all callbacks of ram block notifiers optional David Hildenbrand
2020-02-26 15:52 ` [PATCH v3 05/13] migration/ram: Handle RAM block resizes during precopy David Hildenbrand
2020-02-26 15:52 ` [PATCH v3 06/13] exec: Relax range check in ram_block_discard_range() David Hildenbrand
2020-02-26 15:52 ` [PATCH v3 07/13] migration/ram: Discard RAM when growing RAM blocks after ram_postcopy_incoming_init() David Hildenbrand
2020-02-26 15:52 ` [PATCH v3 08/13] migration/ram: Simplify host page handling in ram_load_postcopy() David Hildenbrand
2020-03-06 16:05   ` Dr. David Alan Gilbert
2020-03-06 16:20     ` David Hildenbrand
2020-03-06 18:47       ` David Hildenbrand
2020-03-06 18:48         ` Dr. David Alan Gilbert
2020-02-26 15:53 ` [PATCH v3 09/13] migration/ram: Consolidate variable reset after placement " David Hildenbrand
2020-03-06 16:30   ` Dr. David Alan Gilbert
2020-03-06 19:09     ` David Hildenbrand
2020-03-06 19:11       ` Dr. David Alan Gilbert
2020-02-26 15:53 ` [PATCH v3 10/13] migration/ram: Handle RAM block resizes during postcopy David Hildenbrand
2020-03-06 16:56   ` Dr. David Alan Gilbert
2020-03-06 18:45     ` David Hildenbrand
2020-03-06 18:51       ` Dr. David Alan Gilbert
2020-02-26 15:53 ` [PATCH v3 11/13] migration/multifd: Print used_length of memory block David Hildenbrand
2020-03-06 16:57   ` Dr. David Alan Gilbert
2020-02-26 15:53 ` [PATCH v3 12/13] migration/ram: Use offset_in_ramblock() in range checks David Hildenbrand
2020-03-06 16:59   ` Dr. David Alan Gilbert
2020-02-26 15:53 ` David Hildenbrand [this message]
2020-02-26 16:06   ` [PATCH v3 13/13] migration/ram: Tolerate partially changed mappings in postcopy code Peter Xu
2020-02-26 16:08     ` David Hildenbrand
2020-02-26 16:26       ` Peter Xu
2020-02-26 16:34         ` 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=20200226155304.60219-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 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.