Re: [Qemu-devel] vm state save/restore question

[Alexander Graf]

On 19.06.2012, at 23:51, Benjamin Herrenschmidt wrote:

> On Tue, 2012-06-19 at 23:48 +0200, Alexander Graf wrote:
>>> We could keep track manually maybe using some kind of dirty bitmap of
>>> changes to the hash table but that would add overhead to things like
>>> H_ENTER.
>> 
>> Only during migration, right?
> 
> True. It will be an "interesting" user/kernel API tho ... I'll give it more 
> thoughts.

Well, all we need is 2 user space pointers in an ENABLE_CAP call. And maybe a 
DISABLE_CAP call to disable the syncing again.

void *htab
u8 *htab_dirty;

ENABLE_CAP(KVM_PPC_SYNC_HTAB, htab, htab_dirty);

which would then make all the current GVA->GPA entries visible to the htab 
pointer. That view is always current. H_ENTER and friends update it in parallel 
to the GVA->HPA htab. We don't have to keep H_ENTER super fast during 
migration, so we can easily go to virtual mode for that one. Any time an entry 
changes, the dirty bitmap gets updated.

Usually, migration ends in killing the VM. But we shouldn't rely on that. 
Instead, we should provide an API to stop the synced mode again. Maybe

  ENABLE_CAP(KVM_PPC_SYNC_HTAB, NULL, NULL);

:)

> I need to understand better how do that vs. qemu save/restore though. IE. 
> That means
> we can't just save the hash as a bulk and reload it, but we'd have to save 
> bits of
> it at a time or something like that no ? Or do we save it once, then save the 
> diff
> at the end ?

The best way would be to throw it into the same bucket as RAM. At the end of 
the day, it really is no different. It'd then be synced during every iteration 
of the migration.


Alex