Re: [PATCH v3 1/6] migration: Allow immutable device state to be migrated early (i.e., before RAM)

[David Hildenbrand]

On 04.01.23 18:23, Peter Xu wrote:
> On Thu, Dec 22, 2022 at 12:02:10PM +0100, David Hildenbrand wrote:
> > Migrating device state before we start iterating is currently impossible.
> > Introduce and use qemu_savevm_state_start_precopy(), and use
> > a new special migration priority -- MIG_PRI_POST_SETUP -- to decide whether
> > state will be saved in qemu_savevm_state_start_precopy() or in
> > qemu_savevm_state_complete_precopy_*().
>
> Can something like this be done in qemu_savevm_state_setup()?

Hi Peter,

Do you mean

(a) Moving qemu_savevm_state_start_precopy() effectively into
    qemu_savevm_state_setup()

(b) Using se->ops->save_setup()

I first tried going via (b), but decided to go the current way of using 
a proper vmstate with properties (instead of e.g., filling the stream 
manually), which also made vmdesc handling possible (and significantly 
cleaner).

Regarding (a), I decided to not move logic of 
qemu_savevm_state_start_precopy() into qemu_savevm_state_setup(), 
because it looked cleaner to save device state with the BQL held and for 
background snapshots, the VM has been stopped. To decouple device state 
saving from the setup path, just like we do it right now for all vmstates.

Having that said, for virtio-mem, it would still work because that state 
is immutable once migration starts, but it felt cleaner to separate the 
setup() phase from actual device state saving.

Thanks!

--
Thanks,

David / dhildenb