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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox