From: Peter Xu <peterx@redhat.com>
To: Steve Sistare <steven.sistare@oracle.com>
Cc: qemu-devel@nongnu.org, Fabiano Rosas <farosas@suse.de>,
David Hildenbrand <david@redhat.com>,
Philippe Mathieu-Daude <philmd@linaro.org>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH] migration: ram block cpr blockers
Date: Fri, 17 Jan 2025 13:16:52 -0500 [thread overview]
Message-ID: <Z4qelNxnBcgO87go@x1n> (raw)
In-Reply-To: <1737135971-132839-1-git-send-email-steven.sistare@oracle.com>
On Fri, Jan 17, 2025 at 09:46:11AM -0800, Steve Sistare wrote:
> +/*
> + * Return true if ram contents would be lost during CPR.
> + * Return false for ram_device because it is remapped in new QEMU. Do not
> + * exclude rom, even though it is readonly, because the rom file could change
> + * in new QEMU. Return false for non-migratable blocks. They are either
> + * re-created in new QEMU, or are handled specially, or are covered by a
> + * device-level CPR blocker. Return false for an fd, because it is visible and
> + * can be remapped in new QEMU.
> + */
> +static bool ram_is_volatile(RAMBlock *rb)
> +{
> + MemoryRegion *mr = rb->mr;
> +
> + return mr &&
> + memory_region_is_ram(mr) &&
> + !memory_region_is_ram_device(mr) &&
> + (!qemu_ram_is_shared(rb) || !qemu_ram_is_named_file(rb)) &&
> + qemu_ram_is_migratable(rb) &&
> + rb->fd < 0;
> +}
Blocking guest_memfd looks ok, but comparing to add one more block
notifier, can we check all ramblocks once in migrate_prepare(), and fail
that command directly if it fails the check?
OTOH, is there any simpler way to simplify the check conditions? It'll be
at least nice to break these checks into smaller if conditions for
readability..
I wonder if we could stick with looping over all ramblocks, then make sure
each of them is on the cpr saved fd list. It may need to make
cpr_save_fd() always register with the name of ramblock to do such lookup,
or maybe we could also cache the ramblock pointer in CprFd, then the lookup
will be a pointer match check.
--
Peter Xu
next prev parent reply other threads:[~2025-01-17 18:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-17 17:46 [PATCH] migration: ram block cpr blockers Steve Sistare
2025-01-17 18:16 ` Peter Xu [this message]
2025-01-17 19:10 ` Steven Sistare
2025-01-17 23:57 ` Peter Xu
2025-01-29 18:20 ` Steven Sistare
2025-01-30 17:01 ` Peter Xu
2025-02-14 20:12 ` Steven Sistare
2025-02-18 16:10 ` Peter Xu
2025-02-25 15:46 ` Steven Sistare
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=Z4qelNxnBcgO87go@x1n \
--to=peterx@redhat.com \
--cc=david@redhat.com \
--cc=farosas@suse.de \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=steven.sistare@oracle.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;
as well as URLs for NNTP newsgroup(s).