From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVb4A-0004id-0e for qemu-devel@nongnu.org; Mon, 27 Jul 2009 21:01:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVb45-0004iD-5o for qemu-devel@nongnu.org; Mon, 27 Jul 2009 21:01:17 -0400 Received: from [199.232.76.173] (port=43121 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVb45-0004i1-2o for qemu-devel@nongnu.org; Mon, 27 Jul 2009 21:01:13 -0400 Received: from mx2.redhat.com ([66.187.237.31]:58797) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MVb43-0005hc-VD for qemu-devel@nongnu.org; Mon, 27 Jul 2009 21:01:12 -0400 Date: Mon, 27 Jul 2009 22:08:07 -0300 From: Glauber Costa Message-ID: <20090728010807.GR4776@poweredge.glommer> References: <1248468005-13907-1-git-send-email-glommer@redhat.com> <4A6AD034.4090802@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A6AD034.4090802@web.de> Subject: [Qemu-devel] Re: [PATCH] RFC: use logging count for individual regions List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, avi@redhat.com 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. 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