From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44326) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaXOg-0001Sb-C4 for qemu-devel@nongnu.org; Tue, 24 Mar 2015 18:34:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YaXOd-0001l4-5N for qemu-devel@nongnu.org; Tue, 24 Mar 2015 18:34:06 -0400 Received: from ozlabs.org ([103.22.144.67]:38419) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaXOc-0001kJ-RG for qemu-devel@nongnu.org; Tue, 24 Mar 2015 18:34:03 -0400 Date: Wed, 25 Mar 2015 09:32:27 +1100 From: David Gibson Message-ID: <20150324223227.GK25043@voom.fritz.box> References: <1424883128-9841-1-git-send-email-dgilbert@redhat.com> <1424883128-9841-21-git-send-email-dgilbert@redhat.com> <20150313010058.GZ11973@voom.redhat.com> <20150313101953.GA2486@work-vm> <20150316061840.GE5741@voom.redhat.com> <20150320123759.GE2468@work-vm> <20150323022542.GG25043@voom.fritz.box> <20150324200414.GG2332@work-vm> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tLveGb43symFnK3n" Content-Disposition: inline In-Reply-To: <20150324200414.GG2332@work-vm> Subject: Re: [Qemu-devel] [PATCH v5 20/45] Modify savevm handlers for postcopy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, quintela@redhat.com, qemu-devel@nongnu.org, amit.shah@redhat.com, pbonzini@redhat.com, yanghy@cn.fujitsu.com --tLveGb43symFnK3n Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 24, 2015 at 08:04:14PM +0000, Dr. David Alan Gilbert wrote: > * David Gibson (david@gibson.dropbear.id.au) wrote: > > On Fri, Mar 20, 2015 at 12:37:59PM +0000, Dr. David Alan Gilbert wrote: > > > * David Gibson (david@gibson.dropbear.id.au) wrote: > > > > On Fri, Mar 13, 2015 at 10:19:54AM +0000, Dr. David Alan Gilbert wr= ote: > > > > > * David Gibson (david@gibson.dropbear.id.au) wrote: > > > > > > On Wed, Feb 25, 2015 at 04:51:43PM +0000, Dr. David Alan Gilber= t (git) wrote: > > > > > > > From: "Dr. David Alan Gilbert" > > > > > > >=20 > > > > > > > Modify save_live_pending to return separate postcopiable and > > > > > > > non-postcopiable counts. > > > > > > >=20 > > > > > > > Add 'can_postcopy' to allow a device to state if it can postc= opy > > > > > >=20 > > > > > > What's the purpose of the can_postcopy callback? There are no = callers > > > > > > in this patch - is it still necessary with the change to > > > > > > save_live_pending? > > > > >=20 > > > > > The patch 'qemu_savevm_state_complete: Postcopy changes' uses > > > > > it in qemu_savevm_state_postcopy_complete and qemu_savevm_state_c= omplete > > > > > to decide which devices must be completed at that point. > > > >=20 > > > > Couldn't they check for non-zero postcopiable state from > > > > save_live_pending instead? > > >=20 > > > That would be a bit weird. > > >=20 > > > At the moment for each device we call the: > > > save_live_setup method (from qemu_savevm_state_begin) > > >=20 > > > 0...multiple times we call: > > > save_live_pending > > > save_live_iterate > > >=20 > > > and then we always call > > > save_live_complete > > >=20 > > >=20 > > > To my mind we have to call save_live_complete for any device > > > that we've called save_live_setup on (maybe it allocated something > > > in _setup that it clears up in _complete). > > >=20 > > > save_live_pending could perfectly well return 0 remaining at the end = of > > > the migrate for our device, and thus if we used that then we wouldn't > > > call save_live_complete. > >=20 > > Um.. I don't follow. I was suggesting that at the precopy->postcopy > > transition point you call save_live_complete for everything that > > reports 0 post-copiable state. > >=20 > >=20 > > Then again, a different approach would be to split the > > save_live_complete hook into (possibly NULL) "complete precopy" and > > "complete postcopy" hooks. The core would ensure that every chunk of > > state has both completion hooks called (unless NULL). That might also > > address my concerns about the no longer entirely accurate > > save_live_complete function name. >=20 > OK, that one I prefer. Are you OK with: > qemu_savevm_state_complete_precopy > calls -> save_live_complete_precopy >=20 > qemu_savevm_state_complete_postcopy > calls -> save_live_complete_postcopy >=20 > ? Sounds ok to me. Fwiw, I was thinking that both the complete_precopy and complete_postcopy hooks should always be called. For a non-postcopy migration, the postcopy hooks would just be called immediately after the precopy hooks. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --tLveGb43symFnK3n Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVEeX7AAoJEGw4ysog2bOSrwwP/A5UR0WgcsRrl77F5o5dbc03 ONL5MPPQkFBYU9eCreG4PXRmJ9wWB345uFh+CPjwQnx242y4il8NIj2xAs+vVzgb sO7naM2Ml39DeS5mSpyKqFsnem8vbbVnFIqmHjCSNIt2+XZw7vPyrT/xPj7eUCEH CTcu73cKIOem1AbiCxLCFi3S2FfyujhTOE0fiAX8TDncwGLdzzbfuFA/sW83uFkr CrcWnpwmfujNm4RKaeQ2Im7mzS1MFObUarpr+ONGnsP/jihZehDJ99drlBKxuJqs ryEPo/apthMSfuINq/5CbunfMDqzfCpKaItOvmMyDDYAF8jks1n02CtqEdmlZo6F Yl9uXGvmD4I14cdr+DWFxJrUBNzYh4NLAxH+gL+GqVS15Qod5Uu35UjD/n8LvyEv f7XhmRo57NqaKYwzAprqNxMY1dTiM0bwyw3NLPEc++xsK80n8Q1cNE2E38NCbNBh X/sa/IkTSV7uWa0fM8VrkKy+H0gRPjKFGIEA1qBY8yB86HfDf2RIuy2pTnOhkR5E LKk2ep/bmCK4s1K7hgEyFEfOS1SONB7mTFW3Ok4k7BJkCfJE833PHpl/MATV9wT7 VJylqAYx56+K+YO+7JnyHvz8oIFwrVajPfZDLVeijtmAg1I9d+KDPTgiTumBOHgA F1+V+C8KLd4eeKEViZr7 =x/Uo -----END PGP SIGNATURE----- --tLveGb43symFnK3n--