qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH] RFC: use logging count for individual regions
Date: Tue, 28 Jul 2009 08:48:49 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]