Re: Merging KVM live migration upstream

[Avi Kivity <avi@redhat.com>]

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.

> 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().

> 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.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.