From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1askTh-0005Fo-Tg for qemu-devel@nongnu.org; Wed, 20 Apr 2016 01:15:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1askTg-0008Hn-75 for qemu-devel@nongnu.org; Wed, 20 Apr 2016 01:15:05 -0400 Date: Wed, 20 Apr 2016 14:32:52 +1000 From: David Gibson Message-ID: <20160420043252.GF1133@voom> References: <1460752385-13259-1-git-send-email-duanj@linux.vnet.ibm.com> <1460752385-13259-3-git-send-email-duanj@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3oCie2+XPXTnK5a5" Content-Disposition: inline In-Reply-To: <1460752385-13259-3-git-send-email-duanj@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH 2/5] Migration: Defined VMStateDescription struct for spapr_drc List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jianjun Duan Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org, mdroth@linux.vnet.ibm.com --3oCie2+XPXTnK5a5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 15, 2016 at 01:33:02PM -0700, Jianjun Duan wrote: > To manage hotplug/unplug of dynamic resources such as PCI cards, > memory, and CPU on sPAPR guests, a firmware abstraction known as > a Dynamic Resource Connector (DRC) is used to assign a particular > dynamic resource to the guest, and provide an interface for the > guest to manage configuration/removal of the resource associated > with it. >=20 > To migrate the hotplugged resources in migration, the > associated DRC state need be migrated. To migrate the DRC state, > we defined the VMStateDescription struct for spapr_drc to enable > the transmission of spapr_drc state in migration. >=20 > Not all the elements in the DRC state are migrated. Only those > ones modifiable by guest actions or device add/remove operation > are migrated. >=20 > Signed-off-by: Jianjun Duan Urgh. It would be really nice if we could avoid this and instead calculate these states from other information. I hate migrating what's essentially transitory state if we can possibly avoid it - is there any way to defer or retry hotplug operations to make this unnececessary? Even if we have to migrate some state here, I'm a bit dubious about whether directly migrating the PAPR indicator states is the best way. It does have the advantage of having a spec, on the other hand the PAPR indicators are really weird and hard to understand the meaning of. > --- > hw/ppc/spapr_drc.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) >=20 > diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c > index 3173940..5f7a25f 100644 > --- a/hw/ppc/spapr_drc.c > +++ b/hw/ppc/spapr_drc.c > @@ -610,6 +610,20 @@ static void spapr_dr_connector_instance_init(Object = *obj) > NULL, NULL, NULL, NULL); > } > =20 > +static const VMStateDescription vmstate_spapr_drc =3D { > + .name =3D "spapr_drc", > + .version_id =3D 1, > + .minimum_version_id =3D 1, > + .fields =3D (VMStateField []) { > + VMSTATE_UINT32(isolation_state, sPAPRDRConnector), > + VMSTATE_UINT32(allocation_state, sPAPRDRConnector), > + VMSTATE_UINT32(indicator_state, sPAPRDRConnector), > + VMSTATE_BOOL(configured, sPAPRDRConnector), > + VMSTATE_BOOL(awaiting_release, sPAPRDRConnector), > + VMSTATE_END_OF_LIST() > + } > +}; > + > static void spapr_dr_connector_class_init(ObjectClass *k, void *data) > { > DeviceClass *dk =3D DEVICE_CLASS(k); > @@ -618,6 +632,7 @@ static void spapr_dr_connector_class_init(ObjectClass= *k, void *data) > dk->reset =3D reset; > dk->realize =3D realize; > dk->unrealize =3D unrealize; > + dk->vmsd =3D &vmstate_spapr_drc; > drck->set_isolation_state =3D set_isolation_state; > drck->set_indicator_state =3D set_indicator_state; > drck->set_allocation_state =3D set_allocation_state; --=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 --3oCie2+XPXTnK5a5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXFwZ0AAoJEGw4ysog2bOS3pwQAOduYi5IzXde2fMBOMLFFoMo 8yBYX7IF1VnRG8LVKUxcMaRB+a3CjyAJ0tO0hiFPvwfn4bTYTpP9AHjRh615Cj2s Eu64pdYbpa6acIOM9QCK5awe4APuvIVCo70M8HL8XviPuedZU+llz1nPHcoMNOo+ RGTttwl5wE+sl57agp3UxfwuiOZBdD7cxgWwQ8X6PAyqSAsZxoQ6wi9j2fGIH13p Q0XhWM84ECoSEAhqFWZj010LSVKxDspob/4InsHHydgAgv/W2GsICfeamGxRwt0Y zmLJhZNsn10CSMSJHM3R8quhmjMeHC2LCp1uCqD9aaUPA2nJTQ6SoneG83gmSOrv vCMUqDiMgwdFLM2KhNLDdvZLmiKA3Llb3cYJ2iNacfRIYDSBt+8RlbJLaafzrFp0 l/FX6t6BCf10VkBvMpwshC2olX1XzGNQRCcKGTnL3jZukKT92eUwWIPkb4dFAT8d JHCIE57EsgHlv8xEkdhh+rgb14BeFBakbHsJxYlfd/aImkwhyc2IEpGakGHw/3lF +HQ5PJQ/w3orh/yzZIFb4DD2+67usZSYMfiVgKi4bS5xbSn02ggHgC7a7PIr1KYo Q2SW8rBDStP4Cx2BugceCUsb69XqSiPkbKn3uDOuWODUUlXevusle3eNxnjEbScg sleUZ28eN0I3VnC3u7sN =MLa1 -----END PGP SIGNATURE----- --3oCie2+XPXTnK5a5--