Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > On Wed, 2012-06-20 at 00:55 +0200, Juan Quintela wrote: >> >> This was going to be my question. >> >> If we can do something like: send hash register, and get a bitmap of >> the >> ones that get changed, we should be good. Perhaps we need something >> "interesting" like removing old entries (no clue if they got just >> overwritten, or how they are replaced), and we should be good. > > Right, we can do an initial "snapshot" and have the kernel start > tracking changes from there. On the final step, we can then request from > the kernel a new snapshot with a dirty bitmap. > > Or we can be even simpler, just do two snapshots and have qemu diff them > itself :-) > > I am confident I can come up with something as far as the kernel and > qemu <-> kernel interface goes. I need to get my head around the details > on how to implement that two stage save process in qemu though and the > corresponding restore which will need to read both snapshots and apply > the diff before shooting it back to the kernel. > > BTW. Does migration in pure qemu (full system emu) works similarily, ie, > two stage ? If it does I can easily prototype everything there.
It does, but I have no clue how the hashed page tables are implemented on ppc, i.e. if there is anything specific for bare metal. Alex? Later, Juan.
