From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: qemu-devel@nongnu.org, "Juan Quintela" <quintela@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
"Leonardo Bras" <leobras@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Peng Tao" <tao.peng@linux.alibaba.com>
Subject: Re: [PATCH v1 4/4] virtio-mem: Support "x-ignore-shared" migration
Date: Tue, 20 Jun 2023 09:06:00 -0400 [thread overview]
Message-ID: <20230620090527-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20230620130354.322180-5-david@redhat.com>
On Tue, Jun 20, 2023 at 03:03:54PM +0200, David Hildenbrand wrote:
> To achieve desired "x-ignore-shared" functionality, we should not
> discard all RAM when realizing the device and not mess with
> preallocation/postcopy when loading device state. In essence, we should
> not touch RAM content.
>
> As "x-ignore-shared" gets set after realizing the device, we cannot
> rely on that. Let's simply skip discarding of RAM on incoming migration.
> Note that virtio_mem_post_load() will call
> virtio_mem_restore_unplugged() -- unless "x-ignore-shared" is set. So
> once migration finished we'll have a consistent state.
>
> The initial system reset will also not discard any RAM, because
> virtio_mem_unplug_all() will not call virtio_mem_unplug_all() when no
> memory is plugged (which is the case before loading the device state).
>
> Note that something like VM templating -- see commit b17fbbe55cba
> ("migration: allow private destination ram with x-ignore-shared") -- is
> currently incompatible with virtio-mem and ram_block_discard_range() will
> warn in case a private file mapping is supplied by virtio-mem.
>
> For VM templating with virtio-mem, it makes more sense to either
> (a) Create the template without the virtio-mem device and hotplug a
> virtio-mem device to the new VM instances using proper own memory
> backend.
> (b) Use a virtio-mem device that doesn't provide any memory in the
> template (requested-size=0) and use private anonymous memory.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> hw/virtio/virtio-mem.c | 47 ++++++++++++++++++++++++++++++++++--------
> 1 file changed, 38 insertions(+), 9 deletions(-)
>
> diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c
> index 9f6169af32..b013dfbaf0 100644
> --- a/hw/virtio/virtio-mem.c
> +++ b/hw/virtio/virtio-mem.c
> @@ -18,6 +18,7 @@
> #include "sysemu/numa.h"
> #include "sysemu/sysemu.h"
> #include "sysemu/reset.h"
> +#include "sysemu/runstate.h"
> #include "hw/virtio/virtio.h"
> #include "hw/virtio/virtio-bus.h"
> #include "hw/virtio/virtio-access.h"
> @@ -886,11 +887,23 @@ static void virtio_mem_device_realize(DeviceState *dev, Error **errp)
> return;
> }
>
> - ret = ram_block_discard_range(rb, 0, qemu_ram_get_used_length(rb));
> - if (ret) {
> - error_setg_errno(errp, -ret, "Unexpected error discarding RAM");
> - ram_block_coordinated_discard_require(false);
> - return;
> + /*
> + * We don't know at this point whether shared RAM is migrated using
> + * QEMU or migrated using the file content. "x-ignore-shared" will be
> + * configurated
configurated == configured?
> after realizing the device. So in case we have an
> + * incoming migration, simply always skip the discard step.
> + *
> + * Otherwise, make sure that we start with a clean slate: either the
> + * memory backend might get reused or the shared file might still have
> + * memory allocated.
> + */
> + if (!runstate_check(RUN_STATE_INMIGRATE)) {
> + ret = ram_block_discard_range(rb, 0, qemu_ram_get_used_length(rb));
> + if (ret) {
> + error_setg_errno(errp, -ret, "Unexpected error discarding RAM");
> + ram_block_coordinated_discard_require(false);
> + return;
> + }
> }
>
> virtio_mem_resize_usable_region(vmem, vmem->requested_size, true);
> @@ -962,10 +975,6 @@ static int virtio_mem_post_load(void *opaque, int version_id)
> RamDiscardListener *rdl;
> int ret;
>
> - if (vmem->prealloc && !vmem->early_migration) {
> - warn_report("Proper preallocation with migration requires a newer QEMU machine");
> - }
> -
> /*
> * We started out with all memory discarded and our memory region is mapped
> * into an address space. Replay, now that we updated the bitmap.
> @@ -978,6 +987,18 @@ static int virtio_mem_post_load(void *opaque, int version_id)
> }
> }
>
> + /*
> + * If shared RAM is migrated using the file content and not using QEMU,
> + * don't mess with preallocation and postcopy.
> + */
> + if (migrate_ram_is_ignored(vmem->memdev->mr.ram_block)) {
> + return 0;
> + }
> +
> + if (vmem->prealloc && !vmem->early_migration) {
> + warn_report("Proper preallocation with migration requires a newer QEMU machine");
> + }
> +
> if (migration_in_incoming_postcopy()) {
> return 0;
> }
> @@ -1010,6 +1031,14 @@ static int virtio_mem_post_load_early(void *opaque, int version_id)
> return 0;
> }
>
> + /*
> + * If shared RAM is migrated using the file content and not using QEMU,
> + * don't mess with preallocation and postcopy.
> + */
> + if (migrate_ram_is_ignored(rb)) {
> + return 0;
> + }
> +
> /*
> * We restored the bitmap and verified that the basic properties
> * match on source and destination, so we can go ahead and preallocate
> --
> 2.40.1
next prev parent reply other threads:[~2023-06-20 13:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-20 13:03 [PATCH v1 0/4] virtio-mem: Support "x-ignore-shared" migration David Hildenbrand
2023-06-20 13:03 ` [PATCH v1 1/4] softmmu/physmem: Warn with ram_block_discard_range() on MAP_PRIVATE file mapping David Hildenbrand
2023-06-21 15:55 ` Peter Xu
2023-06-21 16:17 ` David Hildenbrand
2023-06-21 16:55 ` Peter Xu
2023-06-22 13:10 ` David Hildenbrand
2023-06-22 14:54 ` Peter Xu
2023-06-20 13:03 ` [PATCH v1 2/4] virtio-mem: Skip most of virtio_mem_unplug_all() without plugged memory David Hildenbrand
2023-06-20 13:03 ` [PATCH v1 3/4] migration/ram: Expose ramblock_is_ignored() as migrate_ram_is_ignored() David Hildenbrand
2023-06-21 15:56 ` Peter Xu
2023-06-20 13:03 ` [PATCH v1 4/4] virtio-mem: Support "x-ignore-shared" migration David Hildenbrand
2023-06-20 13:06 ` Michael S. Tsirkin [this message]
2023-06-20 13:40 ` David Hildenbrand
2023-07-06 5:59 ` [PATCH v1 0/4] " Mario Casquero
2023-07-06 7:19 ` 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=20230620090527-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=david@redhat.com \
--cc=leobras@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=tao.peng@linux.alibaba.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.