Re: qemu-kvm.git now live

Jan Kiszka wrote:
> Avi Kivity wrote:
>   
>>>>> Where/how does the
>>>>> migration code disable dirty logging?
>>>>>         
>>>>>           
>>>> Should be phase 3 of ram_save_live().
>>>>     
>>>>         
>>> But only in qemu-kvm. What is the plan about pushing it upstream? Then
>>> we could discuss how to extend the exiting support best.
>>>   
>>>       
>> Pushing things upstream is quite difficult because of the very different
>> infrastructure.
>>     
>
> Isn't the midterm goal to get rid of most of these differences (namely
> libkvm)?
>   

Yes, but not by removing existing functionality.

>   
>> It's unfortunate that upstream rewrote everything
>> instead of changing things incrementally.  Rewrites are almost always a
>> mistake since they throw away accumulated knowledge.
>>     
>
> I disagree, at least in this particular case. Upstream already diverged
> from qemu-kvm, and the latter provided no comparable alternative for
> slot management and dirty logging. And I still don't see that we lost
> anything that could not easily be re-integrated into upstream (ie.
> global dirty logging), finally leading to a cleaner and more complete
> result.
>   

It could have been done differently, by morphing the existing support 
into something mergable, and merging that.  In this way, we'd ensure no 
needed functionality is lost.

As is, we're adding something simple, then discovering it's 
insufficient.  We're throwing away information, that's not a good way to 
make progress.

> So, what bits are missing to make KVM migration work in upstream?
>   

I don't know of anything beyond dirty logging.


-- 
error compiling committee.c: too many arguments to function