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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

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.

As qemu-kvm uses different code here and has different instrumentation
in the devices, it's a bit tricky to asses what it buys upstream. I'm
not against the counting, but I would like to see proper reasoning in
the changelog.

> 
> 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...)
> 
> 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

Good question. From a first glance I would say the logging continues...
What does qemu-kvm do on this? Can't find a cleanup there either.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]