On Tue, Aug 04, 2020 at 08:44:42AM +0000, David Laight wrote: > From: James Bottomley > > Sent: 03 August 2020 16:43 > > > > On Mon, 2020-08-03 at 10:28 -0500, Eric W. Biederman wrote: > > [...] > > > What is wrong with live migration between one qemu process and > > > another qemu process on the same machine not work for this use case? > > > > > > Just reusing live migration would seem to be the simplest path of > > > all, as the code is already implemented. Further if something goes > > > wrong with the live migration you can fallback to the existing > > > process. With exec there is no fallback if the new version does not > > > properly support the handoff protocol of the old version. > > > > Actually, could I ask this another way: the other patch set you sent to > > the KVM list was to snapshot the VM to a PKRAM capsule preserved across > > kexec using zero copy for extremely fast save/restore. The original > > idea was to use this as part of a CRIU based snapshot, kexec to new > > system, restore. However, why can't you do a local snapshot, restart > > qemu, restore using the PKRAM capsule to achieve exactly the same as > > MADV_DOEXEC does but using a system that's easy to reason about? It > > may be slightly slower, but I think we're still talking milliseconds. > > > I've had another idea (that is probably impossible...). > What about a 'reverse mmap' operation. > Something that creates an fd whose contents are a chunk of the > processes address space. http://www.wil.cx/~willy/linux/sileby.html
