Re: Merging KVM live migration upstream

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

Avi Kivity wrote:
> Jan Kiszka wrote:
>> Avi or Uri,
>>
>> could you explain the first and third hunk? Why are they needed in
>> qemu-kvm, and will we also need something comparable upstream? They do
>> not look very beautiful.
>>
>>   
> 
> These date from the bad old days where we relied on phys_ram_base.  I
> think this is obsolete.
> 
> Since we reserve these memory addresses, it won't do any harm, but we
> can certainly remove them.

That's great, will drop it.

> 
>> The second hunk, I guess, should become a kvm hook to
>> cpu_physical_memory_get_dirty - or is this too costly for other users of
>> this inline function?
>>   
> 
> Note the dependency on current_addr: this is meant to happen every time
> we cycle through all memory, so it doesn't fit in
> cpu_physical_memory_get_dirty().

Yes, I realized that there is already cpu_physical_sync_dirty_bitmap(),
and I will simply use this.

> 
>> And does anyone knows further migration-related hunks that are missing
>> upstream (except for the KVM hook in
>> cpu_physical_memory_set_dirty_tracking)?
>>
>>   
> 
> We need to make sure vga plays well with this, like we discussed.

Already implemented in ~30 additional LOC. Just have to test the whole
series (found some more things to clean up)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]