On Mon, Aug 12, 2013 at 12:26 PM, Alex Bligh <alex@xxxxxxxxxxx> wrote: > --On 12 August 2013 11:59:03 +0200 Stefan Hajnoczi <stefanha@xxxxxxxxx> > wrote: > >> The idea that was discussed on qemu-devel@xxxxxxxxxx uses fork(2) to >> capture the state of guest RAM and then send it back to the parent >> process. The guest is only paused for a brief instant during fork(2) >> and can continue to run afterwards. > > > How would you capture the state of emulated hardware which might not > be in the guest RAM? Exactly the same way vmsave works today. It calls the device's save functions which serialize state to file. The difference between today's vmsave and the fork(2) approach is that QEMU does not need to wait for guest RAM to be written to file before resuming the guest. Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
