From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVgX4-0000TJ-Hq for qemu-devel@nongnu.org; Tue, 28 Jul 2009 02:51:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVgWz-0000QG-OX for qemu-devel@nongnu.org; Tue, 28 Jul 2009 02:51:30 -0400 Received: from [199.232.76.173] (port=54044 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVgWy-0000Q7-V9 for qemu-devel@nongnu.org; Tue, 28 Jul 2009 02:51:25 -0400 Received: from mx20.gnu.org ([199.232.41.8]:20722) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MVgWy-0001Et-7f for qemu-devel@nongnu.org; Tue, 28 Jul 2009 02:51:24 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MVgWx-00025S-9D for qemu-devel@nongnu.org; Tue, 28 Jul 2009 02:51:23 -0400 Message-ID: <4A6E9FCC.40909@web.de> Date: Tue, 28 Jul 2009 08:50:52 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1248468005-13907-1-git-send-email-glommer@redhat.com> <4A6AD034.4090802@web.de> <20090728010807.GR4776@poweredge.glommer> <4A6E9C7A.9080705@redhat.com> In-Reply-To: <4A6E9C7A.9080705@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6EA7A7CCE520BF930E13389B" Sender: jan.kiszka@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: Avi Kivity Cc: Glauber Costa , qemu-devel@nongnu.org, aliguori@us.ibm.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6EA7A7CCE520BF930E13389B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > On 07/28/2009 04:08 AM, Glauber Costa wrote: >> On Sat, Jul 25, 2009 at 11:28:20AM +0200, Jan Kiszka wrote: >> =20 >>> Glauber Costa wrote: >>> =20 >>>> 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. >>>> =20 >>> No principle concerns. But before looking into details: what addition= al >>> use cases will it cover (maybe some example from qemu-kvm), or what >>> existing code can it help to simplify? >>> =20 >> >> 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...) >> =20 >=20 > 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. This case is already handled upstream. If we had more users, we would need refcounts. >=20 >> 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 >> =20 >=20 > What about qemu-kvm? Do we clear logging there? >=20 I don't think so. In the end, someone has to call kvm_set_migration_log(0), and so far this only happens in stage 3 which should not be reached in case of an error. Jan --------------enig6EA7A7CCE520BF930E13389B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkpun8wACgkQniDOoMHTA+kApgCfQ6b49s7nY7fCb3dBJuCbVWAE WpYAn07C6x07hhahl+cWy4NOZe7FZKoX =6wlj -----END PGP SIGNATURE----- --------------enig6EA7A7CCE520BF930E13389B--