From: David Hildenbrand <david@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Andrea Arcangeli" <aarcange@redhat.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Juan Quintela" <quintela@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
"Peter Xu" <peterx@redhat.com>, "Paul Durrant" <paul@xen.org>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Shannon Zhao" <shannon.zhao@linaro.org>,
"Igor Mammedov" <imammedo@redhat.com>,
"Anthony Perard" <anthony.perard@citrix.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Richard Henderson" <rth@twiddle.net>
Subject: [PATCH v2 00/13] migrate/ram: Fix resizing RAM blocks while migrating
Date: Fri, 21 Feb 2020 17:41:51 +0100 [thread overview]
Message-ID: <20200221164204.105570-1-david@redhat.com> (raw)
This is the follow up of
"[PATCH RFC] memory: Don't allow to resize RAM while migrating" [1]
This series contains some (slightly modified) patches also contained in:
"[PATCH v2 fixed 00/16] Ram blocks with resizable anonymous allocations
under POSIX" [2]
That series will be based on this series. The last patch (#13) in this
series could be moved to the other series, but I decided to include it in
here for now (similar context).
I realized that resizing RAM blocks while the guest is being migrated
(precopy: resize while still running on the source, postcopy: resize
while already running on the target) is buggy. In case of precopy, we
can simply cancel migration. Postcopy handling is more involved. Resizing
can currently happen during a guest reboot, triggered by ACPI rebuilds.
Along with the fixes, some cleanups.
[1] https://lkml.kernel.org/r/20200213172016.196609-1-david@redhat.com
[2] https://lkml.kernel.org/r/20200212134254.11073-1-david@redhat.com
I was now able to actually test resizing while migrating. I am using the
prototype of virtio-mem to test (which also makes use of resizable
allocations). Things I was able to reproduce:
- Resize while still running on the migration source. Migration is canceled
-- Test case for "migraton/ram: Handle RAM block resizes during precopy"
- Resize (grow+shrink) on the migration target during postcopy migration
(when syncing RAM blocks), while not yet running on the target
-- Test case for "migration/ram: Discard new RAM when growing RAM blocks
and the VM is stopped", and overall RAM size synchronization. Seems to
work just fine.
- Resize (grow+shrink) on the migration tagret during postcopy migration
while already running on the target.
-- Test case for "migration/ram: Handle RAM block resizes during postcopy"
-- Test case for "migration/ram: Tolerate partially changed mappings in
postcopy code" - I can see that -ENOENT is actually triggered and that
migration succeeds. Migration seems to work just fine.
In addition I run avocado-vt migration tests + usual QEMU checks.
v1 -> v2:
- "util: vfio-helpers: Factor out and fix processing of existing ram
blocks"
-- Stringify error
- "migraton/ram: Handle RAM block resizes during precopy"
-- Simplified check if we're migrating on the source
- "exec: Relax range check in ram_block_discard_range()"
-- Added to make discard during resizes actually work
- "migration/ram: Discard new RAM when growing RAM blocks after
ram_postcopy_incoming_init()"
-- Better checks if in the right postcopy mode.
-- Better patch subject/description/comments
- "migration/ram: Handle RAM block resizes during postcopy"
-- Better comments
-- Adapt to changed postcopy checks
- "migrate/ram: Get rid of "place_source" in ram_load_postcopy()"
-- Dropped, as broken
- "migration/ram: Tolerate partially changed mappings in postcopy code"
-- Better comment / description. Clarify that no implicit wakeup will
happen
-- Warn on EINVAL (older kernels)
-- Wake up any waiter explicitly
David Hildenbrand (13):
util: vfio-helpers: Factor out and fix processing of existing ram
blocks
stubs/ram-block: Remove stubs that are no longer needed
numa: Teach ram block notifiers about resizeable ram blocks
numa: Make all callbacks of ram block notifiers optional
migration/ram: Handle RAM block resizes during precopy
exec: Relax range check in ram_block_discard_range()
migration/ram: Discard RAM when growing RAM blocks after
ram_postcopy_incoming_init()
migration/ram: Simplify host page handling in ram_load_postcopy()
migration/ram: Consolidate variable reset after placement in
ram_load_postcopy()
migration/ram: Handle RAM block resizes during postcopy
migration/multifd: Print used_length of memory block
migration/ram: Use offset_in_ramblock() in range checks
migration/ram: Tolerate partially changed mappings in postcopy code
exec.c | 27 +++++--
hw/core/numa.c | 41 +++++++++--
hw/i386/xen/xen-mapcache.c | 7 +-
include/exec/cpu-common.h | 1 +
include/exec/memory.h | 10 +--
include/exec/ramblock.h | 10 +++
include/exec/ramlist.h | 13 ++--
migration/migration.c | 9 ++-
migration/migration.h | 1 +
migration/multifd.c | 2 +-
migration/postcopy-ram.c | 52 +++++++++++++-
migration/ram.c | 144 ++++++++++++++++++++++++++++---------
stubs/ram-block.c | 20 ------
target/i386/hax-mem.c | 5 +-
target/i386/sev.c | 18 ++---
util/vfio-helpers.c | 41 ++++-------
16 files changed, 283 insertions(+), 118 deletions(-)
--
2.24.1
next reply other threads:[~2020-02-21 16:44 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-21 16:41 David Hildenbrand [this message]
2020-02-21 16:41 ` [PATCH v2 01/13] util: vfio-helpers: Factor out and fix processing of existing ram blocks David Hildenbrand
2020-02-21 16:41 ` [PATCH v2 02/13] stubs/ram-block: Remove stubs that are no longer needed David Hildenbrand
2020-02-21 16:41 ` [PATCH v2 03/13] numa: Teach ram block notifiers about resizeable ram blocks David Hildenbrand
2020-02-21 16:41 ` [Xen-devel] " David Hildenbrand
2020-02-21 16:41 ` [PATCH v2 04/13] numa: Make all callbacks of ram block notifiers optional David Hildenbrand
2020-02-21 16:41 ` [PATCH v2 05/13] migration/ram: Handle RAM block resizes during precopy David Hildenbrand
2020-02-24 22:27 ` Peter Xu
2020-02-21 16:41 ` [PATCH v2 06/13] exec: Relax range check in ram_block_discard_range() David Hildenbrand
2020-02-24 22:27 ` Peter Xu
2020-02-21 16:41 ` [PATCH v2 07/13] migration/ram: Discard RAM when growing RAM blocks after ram_postcopy_incoming_init() David Hildenbrand
2020-02-24 22:28 ` Peter Xu
2020-02-21 16:41 ` [PATCH v2 08/13] migration/ram: Simplify host page handling in ram_load_postcopy() David Hildenbrand
2020-02-21 16:42 ` [PATCH v2 09/13] migration/ram: Consolidate variable reset after placement " David Hildenbrand
2020-02-21 16:42 ` [PATCH v2 10/13] migration/ram: Handle RAM block resizes during postcopy David Hildenbrand
2020-02-24 22:26 ` Peter Xu
2020-02-25 7:28 ` David Hildenbrand
2020-02-25 16:11 ` Peter Xu
2020-02-21 16:42 ` [PATCH v2 11/13] migration/multifd: Print used_length of memory block David Hildenbrand
2020-02-21 16:42 ` [PATCH v2 12/13] migration/ram: Use offset_in_ramblock() in range checks David Hildenbrand
2020-02-21 16:42 ` [PATCH v2 13/13] migration/ram: Tolerate partially changed mappings in postcopy code David Hildenbrand
2020-02-24 22:49 ` Peter Xu
2020-02-25 7:44 ` David Hildenbrand
2020-02-25 14:27 ` Peter Xu
2020-02-25 15:37 ` Peter Xu
2020-02-21 18:04 ` [PATCH v2 00/13] migrate/ram: Fix resizing RAM blocks while migrating Peter Xu
2020-02-24 9:09 ` David Hildenbrand
2020-02-24 17:45 ` Peter Xu
2020-02-24 18:44 ` David Hildenbrand
2020-02-24 18:59 ` David Hildenbrand
2020-02-24 19:18 ` Peter Xu
2020-02-24 19:34 ` David Hildenbrand
2020-02-24 20:04 ` Peter Xu
2020-02-24 20:54 ` 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=20200221164204.105570-1-david@redhat.com \
--to=david@redhat.com \
--cc=aarcange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=alex.williamson@redhat.com \
--cc=anthony.perard@citrix.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=richard.henderson@linaro.org \
--cc=rth@twiddle.net \
--cc=shannon.zhao@linaro.org \
--cc=sstabellini@kernel.org \
--cc=stefanha@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.