Re: [Qemu-devel] Re: [PATCH 3/3] Add KVM support to QEMU

[Avi Kivity <avi@redhat.com>]

Glauber Costa wrote:
>>> Another place "hook" is updating a slot's dirty bitmap.  Right now,  
>>> with my patchset we don't have live migration or the VGA RAM  
>>> optimization.  There's nothing about the VGA RAM optimization that  
>>> wouldn't work for QEMU.  I'm not sure that it really is an  
>>> optimization in the context of TCG, but I certainly don't think it's  
>>> any worse.  The only thing you really need is to query the KVM dirty  
>>> bitmap when it comes time to enable start over querying the VGA dirty  
>>> bits.
>>>       
>> I don't understand this.  The VGA optimization really is qemu's, the kvm  
>> modifications only cater to the different way of getting the dirty bits.
>>     
>
> As it seems to me, the real difference is that qemu has to explicitly set
> certain regions as dirty, while kvm get dirty bit "automatically" from the kernel.
>
>   

I'm completely lost.  I don't see how one or the other is more or less 
automatic, or how qemu has to explicitly set regions as dirty (except 
when emulating bitblt).

> So I believe we can have markers on the code to refresh dirty bitmap for certain
> area ranges (for kvm use), and also enable a manual override (for qemu). After that,
> the cpu_physical_memory_get_dirty() will simply return whether or not the page is
> dirty.
>   

Does not cpu_p_m_g_dirty() simply return whether or not the page is 
dirty now?

> Also, kvm only tracks "dirty" bits, whereas qemu has at least three kinds of them.
> But I think for now we can assume that kvm's dirty mean "all dirty

kvm's dirty bits mean that kvm has seen the page written to since the 
last query.  A zero doesn't mean the page is clean though -- it could 
have been written to by qemu.

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