From: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
To: "Denis V. Lunev" <den@openvz.org>, svt-core@virtuozzo.com
Subject: Re: [PATCH v2 hci-8.0] hostmem: fix live update crash of VMs with bound guest memory #VSTOR-147016
Date: Thu, 24 Sep 2026 13:34:28 +0300 [thread overview]
Message-ID: <bad7d09d-4e31-411d-826b-1e8ed6102041@virtuozzo.com> (raw)
In-Reply-To: <20260923173105.3576937-1-den@openvz.org>
LGTM
Ack
On 9/23/26 8:31 PM, Denis V. Lunev wrote:
> From: Denis V. Lunev <den@openvz.org>
>
> A live QEMU update kills a VM whose memory backend has host-nodes when
> the emulator cgroup no longer allows those nodes. The old QEMU saves its
> state, the new one exits during startup with
>
> qemu-kvm: cannot bind memory to host NUMA nodes: Invalid argument
>
> and the guest is lost.
>
> Guest RAM survives cpr-exec as the same anonymous mapping, carrying its
> pages and its memory policy. host_memory_backend_memory_complete() does
> not know that and treats it as fresh memory: it calls mbind() with
> MPOL_MF_STRICT | MPOL_MF_MOVE and preallocates again. The exec keeps the
> PID and the cgroup, so if cpuset.mems has been changed to nodes outside
> host-nodes since the VM started, mbind() returns EINVAL and QEMU exits.
> Where it succeeds, it only walks or migrates pages that are already in
> place, while the guest is stopped.
>
> Skip the NUMA binding and preallocation for an anonymous backend on
> incoming cpr-exec. ram_block_add() refuses to allocate anonymous RAM in
> that mode, so such a block is always an inherited one. Backends with an
> fd get a new mapping after the exec and keep mbind(), and memory added
> after the update is back on the normal path.
>
> Suggested-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> ---
> backends/hostmem.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/backends/hostmem.c b/backends/hostmem.c
> index 35734d6f4d1..bb7f0c4c18f 100644
> --- a/backends/hostmem.c
> +++ b/backends/hostmem.c
> @@ -22,6 +22,7 @@
> #include "qemu/madvise.h"
> #include "qemu/cutils.h"
> #include "hw/qdev-core.h"
> +#include "migration/cpr.h"
>
> #ifdef CONFIG_NUMA
> #include <numaif.h>
> @@ -363,6 +364,10 @@ host_memory_backend_memory_complete(UserCreatable *uc, Error **errp)
> if (!backend->dump) {
> qemu_madvise(ptr, sz, QEMU_MADV_DONTDUMP);
> }
> + /* Anonymous memory is inherited on cpr-exec with its policy and pages */
> + if (cpr_exec_is_incoming() && memory_region_get_fd(&backend->mr) < 0) {
> + return;
> + }
> #ifdef CONFIG_NUMA
> unsigned long lastbit = find_last_bit(backend->host_nodes, MAX_NODES);
> /* lastbit == MAX_NODES means maxnode = 0 */
>
> base-commit: e8a73d39faf578d58aa2c4b4b024226796c390e6
prev parent reply other threads:[~2026-09-24 10:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 17:31 Denis V. Lunev
2026-09-24 10:34 ` Andrey Drobyshev [this message]
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=bad7d09d-4e31-411d-826b-1e8ed6102041@virtuozzo.com \
--to=andrey.drobyshev@virtuozzo.com \
--cc=den@openvz.org \
--cc=svt-core@virtuozzo.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.