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. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
