* Paolo Bonzini (pbonz...@redhat.com) wrote:
> Il 04/07/2014 19:41, Dr. David Alan Gilbert (git) ha scritto:
> >From: "Dr. David Alan Gilbert" <dgilb...@redhat.com>
> >
> >Postcopy needs to have two migration streams loading concurrently;
> >one from memory (with the device state) and the other from the fd
> >with the memory transactions.
>
> Can you explain this?
>
> I would have though the order is
>
> precopy RAM and everything
> prepare postcopy RAM ("sent && dirty" bitmap)
> finish precopy non-RAM
> finish devices
> postcopy RAM
>
> Why do you need to have all the packaging stuff and a separate memory-based
> migration stream for devices? I'm sure I'm missing something. :)
The thing you're missing is the details of 'finish devices'.
The device emulation may access guest memory as part of loading it's
state, so you can't successfully complete 'finish devices' without
having the 'postcopy RAM' available to provide pages.
Thus you need to be able to start up 'postcopy RAM' before 'finish devices'
has completed, and you can't do that if 'finish devices' is still stuffing
data down the fd.
Now, if hypothetically you had:
1) A migration format that let you separate out device state so that you
could load all the state of the device off the fd without calling the device
IO code.
2) All devices were good and didn't touch guest memory while loading their
state.
then you could avoid this complexity. However, if you look at how Stefan's
BER code tried to do 1 (which I don't do in my way of doing it), it was by
using the same trick of stuffing the device data into a dummy memory file
to find out the size of the data. And I'm not convinced (2) will happen
this century.
> Paolo
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
