Not against it if you want to keep exploring, but if so please avoid using
the priority field, also I'd hope the early vmsd will be saved within
qemu_savevm_state_setup() so maybe it can be another alternative to
save_setup().
Maybe it's still easier we keep going with the save_setup() and the shim
functions above, if it works for you.
I'll happy to go the path you suggested if we can make it work. I'd be happy
to have something "reasonable" for the virtio-mem device in the
analyze-migration.py output. But I could live with just nothing useful for
the device itself -- as long as at least the other devices still show up.
So, let's see whether we can go back to the load_state() approach..
static const SaveVMHandlers vmstate_virtio_mem_device_early_ops = {
.save_setup = virtio_mem_save_setup_early,
.save_state = virtio_mem_save_state_early,
.load_state = virtio_mem_load_state_early,
};
vfio handled it using a single header flag for either save_setup() or
save_state(), then load_state() identifies it:
data = qemu_get_be64(f);
...
switch (data) {
case VFIO_MIG_FLAG_DEV_CONFIG_STATE:
...
case VFIO_MIG_FLAG_DEV_SETUP_STATE:
...
Maybe play the same trick here? The flag needs to be hard coded but at
least not the vmsd. Based on previous experience, I could have missed
something else, though. :)
I could also remember "internally" if load_state() was already called
throughout the migartion I think.
But, IIUC, it will still make analyze-migration.py produce wrong
results, because of the vmdesc mismatch.
Or if you like go the other way I'm fine too.
IMHO my approach will be cleaner on the device side but will require
migration code changes. I'll try getting that as clean as possible for
now and resend. If there are more ideas on how to get the other approach
running, I'll be happy to try.
Thanks!
--
Thanks,
David / dhildenb
