From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVgIw-0004aT-Mk for qemu-devel@nongnu.org; Tue, 28 Jul 2009 02:36:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVgIr-0004WI-No for qemu-devel@nongnu.org; Tue, 28 Jul 2009 02:36:53 -0400 Received: from [199.232.76.173] (port=55564 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVgIr-0004Vz-DZ for qemu-devel@nongnu.org; Tue, 28 Jul 2009 02:36:49 -0400 Received: from mx2.redhat.com ([66.187.237.31]:40030) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MVgIq-0001wi-9U for qemu-devel@nongnu.org; Tue, 28 Jul 2009 02:36:48 -0400 Message-ID: <4A6E9C7A.9080705@redhat.com> Date: Tue, 28 Jul 2009 09:36:42 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1248468005-13907-1-git-send-email-glommer@redhat.com> <4A6AD034.4090802@web.de> <20090728010807.GR4776@poweredge.glommer> In-Reply-To: <20090728010807.GR4776@poweredge.glommer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Glauber Costa Cc: aliguori@us.ibm.com, Jan Kiszka , qemu-devel@nongnu.org On 07/28/2009 04:08 AM, 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. > > 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...) > Unlike the qemu dirty byte-map, the kvm dirty log can only service one user. As we have multiple users (vga and migration), we need some way to fix this impedance mismatch. I think refcounts are the easiest. > 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 > What about qemu-kvm? Do we clear logging there? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.