Re: [PATCH] migration: add FEATURE_SEEKABLE to QIOChannelBlock

[Peter Xu <peterx@redhat.com>]

On Thu, Apr 24, 2025 at 03:44:49PM +0200, Marco Cavenati wrote:
> > If we decide we need to explicitly select that new code, I don't think
> > we need any new capability, because the user has no choice in it. We
> > know that loadvm needs it, but -loadvm doesn't, any other sort of
> > mapped-ram migration also doesn't need it. There is some discussion to
> > be had on whether we want to bind it to the commands themselves, or do
> > some form of detection of clean ram. I think it's best we postopone this
> > part of the discussion until Peter is back (next week), so we can have
> > more eyes on it.

Some more eyes are back, useful or not. :)

> 
> The scenarios where zeroing is not required (incoming migration and
> -loadvm) share a common characteristic: the VM has not yet run in the
> current QEMU process.
> To avoid splitting read_ramblock_mapped_ram(), could we implement
> a check to determine if the VM has ever run and decide whether to zero
> the memory based on that? Maybe using RunState?
> 
> Then we can add something like this to read_ramblock_mapped_ram()
> ...
> clear_bit_idx = 0;
> for (...) {
>     // Zero pages
>     if (guest_has_ever_run()) {
>         unread = TARGET_PAGE_SIZE * (set_bit_idx - clear_bit_idx);
>         offset = clear_bit_idx << TARGET_PAGE_BITS;
>         host = host_from_ram_block_offset(block, offset);
>         if (!host) {...}
>         ram_handle_zero(host, unread);
>     }
>     // Non-zero pages
>     clear_bit_idx = find_next_zero_bit(bitmap, num_pages, set_bit_idx + 1);
> ...
> (Plus trailing zero pages handling)

[...]

> > >> > In a nutshell, I'm using dirty page tracking to load from the snapshot
> > >> > only the pages that have been dirtied between two loadvm;
> > >> > mapped-ram is required to seek and read only the dirtied pages.

I may not have the full picture here, please bare with me if so.

It looks to me the major feature here you're proposing is like a group of
snapshots in sequence, while only the 1st snapshot contains full RAM data,
the rest only contains what were dirtied?

From what I can tell, the interface will be completely different from
snapshots then - firstly the VM will be running when taking (at least the
2nd+) snapshots, meanwhile there will be an extra phase after normal save
snapshot, which is "keep saving snapshots", during the window the user is
open to snapshot at any time based on the 1st snapshot.  I'm curious what's
the interfacing for the feature.  It seems we need a separate command
saying that "finished storing the current group of snapshots", which should
stop the dirty tracking.

I'm also curious what is the use case, and I also wonder if "whether we
could avoid memset(0) on a zero page" is anything important here - maybe
you could start with simple (which is to always memset() for a zero page
when a page is dirtied)?

Thanks,

-- 
Peter Xu