From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55059) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsLyj-0001Lo-02 for qemu-devel@nongnu.org; Thu, 06 Oct 2016 23:37:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bsLyf-00082r-P1 for qemu-devel@nongnu.org; Thu, 06 Oct 2016 23:37:44 -0400 Date: Fri, 7 Oct 2016 14:36:07 +1100 From: David Gibson Message-ID: <20161007033607.GO18490@umbus.fritz.box> References: <1475519097-27611-1-git-send-email-duanj@linux.vnet.ibm.com> <1475519097-27611-6-git-send-email-duanj@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7pXD3OQNRL3RjWCz" Content-Disposition: inline In-Reply-To: <1475519097-27611-6-git-send-email-duanj@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [QEMU PATCH v5 5/6] migration: spapr: migrate ccs_list in spapr state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jianjun Duan Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org, dmitry@daynix.com, peter.maydell@linaro.org, kraxel@redhat.com, mst@redhat.com, pbonzini@redhat.com, veroniabahaa@gmail.com, quintela@redhat.com, amit.shah@redhat.com, mreitz@redhat.com, kwolf@redhat.com, rth@twiddle.net, aurelien@aurel32.net, leon.alrae@imgtec.com, blauwirbel@gmail.com, mark.cave-ayland@ilande.co.uk, mdroth@linux.vnet.ibm.com, dgilbert@redhat.com --7pXD3OQNRL3RjWCz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 03, 2016 at 11:24:56AM -0700, Jianjun Duan wrote: > ccs_list in spapr state maintains the device tree related > information on the rtas side for hotplugged devices. In racing > situations between hotplug events and migration operation, a rtas > hotplug event could be migrated from the source guest to target > guest, or the source guest could have not yet finished fetching > the device tree when migration is started, the target will try > to finish fetching the device tree. By migrating ccs_list, the > target can fetch the device tree properly. >=20 > ccs_list is put in a subsection in the spapr state VMSD to make > sure migration across different versions is not broken. >=20 > Signed-off-by: Jianjun Duan I'm still not entirely convinced we need to migrate the ccs_list. What would happen if we did this: * Keep a flag which indicates whether the guest is in the middle of the configure_connector process. - I'm not sure if that would need to be a new bit of state, or if we could deduce it from the value of the isolation and allocation states - If it's new state, we'd need to migrate it, obviously not if we can derive it from other state flags * On the destination during post_load, if there was an in-progress configure_connector on the source, we set another "stale configure" flag * When a configure_connector call is attempted on the destination with the stale configure flag set, return an error The question is, if we choose the right error, can we get the guest to either restart the configure from scratch, or fail gracefully, so the operator can restart the hotplug > --- > hw/ppc/spapr.c | 34 ++++++++++++++++++++++++++++++++++ > 1 file changed, 34 insertions(+) >=20 > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > index 63b6a0d..1847d35 100644 > --- a/hw/ppc/spapr.c > +++ b/hw/ppc/spapr.c > @@ -1255,6 +1255,36 @@ static bool version_before_3(void *opaque, int ver= sion_id) > return version_id < 3; > } > =20 > +static bool spapr_ccs_list_needed(void *opaque) > +{ > + sPAPRMachineState *spapr =3D (sPAPRMachineState *)opaque; > + return !QTAILQ_EMPTY(&spapr->ccs_list); > +} > + > +static const VMStateDescription vmstate_spapr_ccs =3D { > + .name =3D "spaprconfigureconnectorstate", > + .version_id =3D 1, > + .minimum_version_id =3D 1, > + .fields =3D (VMStateField[]) { > + VMSTATE_UINT32(drc_index, sPAPRConfigureConnectorState), > + VMSTATE_INT32(fdt_offset, sPAPRConfigureConnectorState), > + VMSTATE_INT32(fdt_depth, sPAPRConfigureConnectorState), > + VMSTATE_END_OF_LIST() > + }, > +}; > + > +static const VMStateDescription vmstate_spapr_ccs_list =3D { > + .name =3D "spaprccslist", > + .version_id =3D 1, > + .minimum_version_id =3D 1, > + .needed =3D spapr_ccs_list_needed, > + .fields =3D (VMStateField[]) { > + VMSTATE_QTAILQ_V(ccs_list, sPAPRMachineState, 1, > + vmstate_spapr_ccs, sPAPRConfigureConnectorState= , next), > + VMSTATE_END_OF_LIST() > + }, > +}; > + > static const VMStateDescription vmstate_spapr =3D { > .name =3D "spapr", > .version_id =3D 3, > @@ -1270,6 +1300,10 @@ static const VMStateDescription vmstate_spapr =3D { > VMSTATE_PPC_TIMEBASE_V(tb, sPAPRMachineState, 2), > VMSTATE_END_OF_LIST() > }, > + .subsections =3D (const VMStateDescription*[]) { > + &vmstate_spapr_ccs_list, > + NULL > + } > }; > =20 > static int htab_save_setup(QEMUFile *f, void *opaque) --=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 --7pXD3OQNRL3RjWCz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJX9xgkAAoJEGw4ysog2bOSDgoP/3FfjPOJ364n/s3xHuSBlbuj dLo05Ll9WRWazzpBWJ/HWLWTDemtd+ai462Anu99Db5k67t1+v0LLWfb3d2KuAU6 EK4JO9vBCepM1G+lQN2zFdqLfyKaHeuJj7bbCxu08kpLsYyFyT+dUptm4mvylaK1 rSqR1DjsmAmBBoL/yeU4jfyrkAYTgq9I/pOP+SRmFWFir9xSR499LSiTq8ShF/s9 67U15+Mz0BFVRogV6DhMA62LXE4wQF0zde6g/zw+w7cmhe18Txs0WEbs7KfxcFrB WCHSbWxVTu4zHcQrQxjdK2IrzkCPL7RxNrgCxsQQnvQwKcCzqNLlP6S3AZehvi8m 282I6yZrTDw8/qhFU4Q0ip6/Bi1xKuiJFgOY7XIVI3sbQuhKAH24ecTJnPk6h2dV 2VwnSAbSRPUYwR8rYshTvtRLiJqidW6Xc6ySxtFVib5J3aTEvpyqBnfRQIqPky58 GTy3vR7WB58bfkm81HP9x5ze3+gQmpNpgrsZkC9/uSt6+UermUrdbDGUkVce26Q1 fgP1qBKMwu2Ah2dT+ZVKJJmWycOdH5WCqT8oXwL0hqldxQFU+5HOwoN3Ava8feet zz4dltGnqTjehAoMAFpJjuH5MEh8gNu4+z1icLSTbMoSHiHyeoktszE7qBFwBL2C kSM+wDJ3Kdo9FQHzAgAl =IO+U -----END PGP SIGNATURE----- --7pXD3OQNRL3RjWCz--