Avi Kivity wrote:
> On 07/28/2009 04:08 AM, Glauber Costa wrote:
>> On Sat, Jul 25, 2009 at 11:28:20AM +0200, Jan Kiszka wrote:
>>   
>>> Glauber Costa wrote:
>>>     
>>>> qemu-kvm use this scheme of logging count of individual regions,
>>>> which is, IMHO, more flexible which the one we have right now.
>>>> I'm proposing we use it.
>>>>
>>>> Anthony, please don't apply this patch yet, as I would want it
>>>> to receive proper testing, and FYI, current migration broken ;(
>>>> - and I don't really have time to go debug it now.
>>>>
>>>> Jan: Please let me know what you think of it.
>>>>        
>>> No principle concerns. But before looking into details: what additional
>>> use cases will it cover (maybe some example from qemu-kvm), or what
>>> existing code can it help to simplify?
>>>      
>>
>> Maybe avi can provide more input here, but to the very least, I
>> believe this
>> approach is more proven, since it lived in qemu-kvm for a while now.
>> Although more
>> cumbersome, the bits in avi's tree usually work better for kvm-related
>> stuff.
>>
>> I don't see a particular code path it simplifies, but I believe it can
>> help us finding
>> bugs that will manifest in the form of an unbalanced count. It will
>> also work if we ever
>> happen to have two entities manipulating dirty bits in the VGA region,
>> like if we some day
>> implement dual head or something (although one might arguee that we
>> should change it when
>> the time comes...)
>>    
> 
> Unlike the qemu dirty byte-map, the kvm dirty log can only service one
> user.  As we have multiple users (vga and migration), we need some way
> to fix this impedance mismatch.  I think refcounts are the easiest.

This case is already handled upstream. If we had more users, we would
need refcounts.

> 
>> Btw, a side note: in your current scheme, what we do when migration
>> fail? Do we keep migration_log
>> up ? I can't find any place in the code where we put it down
>>    
> 
> What about qemu-kvm?  Do we clear logging there?
> 

I don't think so. In the end, someone has to call
kvm_set_migration_log(0), and so far this only happens in stage 3 which
should not be reached in case of an error.

Jan