Re: [Qemu-devel] [PATCH v2 00/51] Creating RAMState for migration

[Dr. David Alan Gilbert]

* Juan Quintela (address@hidden) wrote:
> "Dr. David Alan Gilbert" <address@hidden> wrote:
> > * Juan Quintela (address@hidden) wrote:
> >> Hi
> >
> > Some high level points:
> >
> >> Continuation of previous series, all review comments addressed. New things:
> >> - Consolidate all function comments in the same style (yes, docs)
> >> - Be much more careful with maintaining comments correct
> >> - Move all postcopy fields to RAMState
> >
> >> - Move QEMUFile to RAMState
> >> - rename qemu_target_page_bits() to qemu_target_page_size() to reflect use
> >> - Remove MigrationState from functions that don't need it
> >> - reorganize last_sent_block to the place where it is used/needed
> >> - Move several places from offsets to pages
> >> - Rename last_ram_offset() to last_ram_page() to refect use
> >
> > An interesting question is what happens if we ever have multiple threads
> > working on RAM at once, I assume you're thinking there will be multiple
> > RAMStates?  It'll be interesting to see whether everything we have now got
> > in RAMState is stuff that wants to be replicated that way.
> 
> Working on paolo suggestion on sending everyhting through multiplefd's.
> That requires multiple FD's.

Yes, but for example do we want multiple postcopy request queues?
Do we have one reverse stream for requests or multiple?

Dave

> Thanks, Juan.
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK