On Wed, Oct 29, 2008 at 02:39:57PM +0200, Avi Kivity wrote:
> 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).
Or maybe I am. But I don't see any way in which qemu sets dirty bits but
explicitly with cpu_physical_memory_set_dirty(). This is pretty explicit.
>
>> 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?
If you look at the vga code, you see something like:
cpu_physical_memory_get_dirty(page0, VGA_DIRTY_FLAG) |
cpu_physical_memory_get_dirty(page1, VGA_DIRTY_FLAG);
if (kvm_enabled()) {
update |= bitmap_get_dirty(bitmap, (page0 - s->vram_offset) >>
TARGET_PAGE_BITS);
update |= bitmap_get_dirty(bitmap, (page1 - s->vram_offset) >>
TARGET_PAGE_BITS);
}
so if the page is not dirty to cpu_p_m_g_dirty() (I liked that abb), it can
still be dirty
for kvm. Ideally, it would not be necessary.
>
>> 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.
Right.
The point here is more like kvm has 1 type of dirty whereas qemu has many.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
