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. Thanks, -- Peter Xu
