Re: [PATCH] migration: add FEATURE_SEEKABLE to QIOChannelBlock

[Peter Xu <peterx@redhat.com>]

On Fri, May 09, 2025 at 11:14:41PM +0200, Marco Cavenati wrote:
> On Friday, May 09, 2025 18:21 CEST, Peter Xu <peterx@redhat.com> wrote:
>  
> > So you don't really need to take sequence of snapshots?  Hmm, that sounds
> > like a completely different use case that I originally thought.
> 
> Correct
> 
> > Have you thought of leveraging ignore-shared and MAP_PRIVATE for the major
> > chunk of guest mem?
> > 
> > Let me explain; it's a very rough idea, but maybe you can collect something
> > useful.
> > 
> > So.. if you keep reloading one VM state thousands of times, it's better
> > first that you have some shmem file (let's imagine that's enough.. you
> > could have more backends) keeping the major chunk of the VM RAM image that
> > you migrated before into a file.
> > 
> > Say, the major part of guest mem is stored here:
> > 
> >   PATH_RAM=/dev/shm/XXX
> > 
> > Then you migrate (with ignore-shared=on) to a file here (NOTE: I _think_
> > you really can use file migration in this case with VM stopped first, not
> > snapshot save/load):
> > 
> >   PATH_VM_IMAGE=/tmp/VM_IMAGE_YYY
> > 
> > Then, the two files above should contain all info you need to start a new
> > VM.
> > 
> > When you want to recover that VM state, boot a VM using this cmdline:
> > 
> >   $qemu ... \
> >   -object memory-backend-file,mem-path=$PATH_RAM,share=off
> >   -incoming file:$PATH_VM_IMAGE
> > 
> > That'll boot a VM, directly loading the shmem page cache (always present on
> > the host, occupying RAM, though, outside of VM lifecycle, but it's part of
> > the design..), loading VM image would be lightning fast because it's tiny
> > when there's almost no RAM inside.  No concern on mapped-ram at all as the
> > rest RAMs are too trivial to just be a stream.
> > 
> > The important bit is share=off - that will mmap() the VM major RAM as
> > MAP_PRIVATE, then it'll do CoW on the "snapshot" you made before, whenever
> > you writes to some guest pages during fuzzing some functions, it copies the
> > shmem page cache over.  shmem page cache should never change its content.
> > 
> > Sounds working to you?
> 
> I didn't know much about these options, cool, thanks for the explanation.
> 
> My only concern is that I'd have to restart the QEMU process for each iteration.
> Honestly I've never measured the impact it would have but I fear that it would 
> be noticeable since the goal is to restore many times a second. What do you
> think?

It may depends on how "many times" are defined. :) IIUC, booting QEMU could
still be pretty fast, but yes, worth measuring.

If that works at least functionally (which also needs some double checking
I guess..), it would be great if you would compare the perf difference
v.s. your solution, that'll be very helpful material for reviewers to read
when/if you're going to propose the feature.

> (Also, snapshots conveniently take care of the disk as well, but this shouldn't 
> be too big of a deal.)

True, I didn't take disks into consideration.  Maybe disk files can be
snapshotted and recovered separately using either qcow2's snapshots, or
using snapshots on modern file systems like btrfs.  Good to know you seem
to have ways to work it out in all cases.

-- 
Peter Xu