RE: [RFC PATCH 0/5] madvise MADV_DOEXEC

[David Laight]

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)