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

Avi Kivity
2008-10-29T12:40:06Z

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