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

[Avi Kivity]

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