On 2026/09/30 4:22, Peter Xu wrote:
On Tue, Sep 29, 2026 at 03:16:39PM -0400, Peter Xu wrote:
On Tue, Sep 29, 2026 at 07:34:50PM +0100, David Woodhouse wrote:
On Tue, 2026-09-29 at 14:22 -0400, Peter Xu wrote:
On Tue, Sep 29, 2026 at 08:23:23PM +0300, Andrey Drobyshev wrote:
The snapshot RAM-saving path does not support Xen's memory mappings.
Refuse 'savevm' and 'loadvm' when running as a Xen device model, the
same way they are refused for CPR migration modes.
Suggested-by: Akihiko Odaki <[email protected]>
Signed-off-by: Andrey Drobyshev <[email protected]>
Acked-by: Peter Xu <[email protected]>
Cc: David Woodhouse <[email protected]>
Cc: Paul Durrant <[email protected]>
Hm, but surely if QEMU is running as a device model for a Xen domain,
all it should be saving and restoring is that device model. It's then
up to Xen and its toolstack to migrate the domain and its memory.
We've had guest-transparent live migration working on Xen, as well as
in-place update of QEMU on the same host. Surely all of those require
save/load support?
Looks like I was wise copying more people..
I knew Xen had qmp_xen_save_devices_state(), I was thinking that is the
save support wiring together with Xen's facilities.
I confess I never know what is the load support, and I was taking it for
granted RAM was managed elsewhere, so load perhaps the same.
So I suppose this is still a question to the author, or maybe Akihiko?
Ok, I just noticed xen also has @xen-load-devices-state, so maybe this is
the answer. I suppose Xen should be using those, rather than the default
savevm/loadvm.
Note, that what this patch changes (migrate_can_snapshot()) only affects
savevm/loadvm command.
That aligns with my understanding as well, so:
Reviewed-by: Akihiko Odaki <[email protected]>
Regards,
Akihiko Odaki
