[Qemu-devel] Re: [PATCH] RFC: use logging count for individual regions

[Avi Kivity <avi@redhat.com>]

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.

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

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.