Re: qemu-kvm.git now live

Avi Kivity wrote:
> 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.

No one said this.

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

The existing support lacked features upstream already had and instead
required additional hacks to make qemu-kvm work.

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

I doubt this applies here.

> 
>> So, what bits are missing to make KVM migration work in upstream?
>>   
> 
> I don't know of anything beyond dirty logging.
> 

OK, then I will pick this up and have a look at something comparable to
cpu_physical_memory_set_dirty_tracking() for upstream.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux