From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsLyh-0001Lg-4Z for qemu-devel@nongnu.org; Thu, 06 Oct 2016 23:37:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bsLyf-000832-UG for qemu-devel@nongnu.org; Thu, 06 Oct 2016 23:37:43 -0400 Date: Fri, 7 Oct 2016 13:54:42 +1100 From: David Gibson Message-ID: <20161007025442.GK18490@umbus.fritz.box> References: <1475519097-27611-1-git-send-email-duanj@linux.vnet.ibm.com> <1475519097-27611-2-git-send-email-duanj@linux.vnet.ibm.com> <20161005101254.GD2036@work-vm> <9dc23ca2-9ca6-9b2e-9c22-257d11e234d1@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/rDaUNvWv5XYRSKj" Content-Disposition: inline In-Reply-To: <9dc23ca2-9ca6-9b2e-9c22-257d11e234d1@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [QEMU PATCH v5 1/6] migration: alternative way to set instance_id in SaveStateEntry List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jianjun Duan Cc: "Dr. David Alan Gilbert" , 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 --/rDaUNvWv5XYRSKj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 05, 2016 at 09:44:57AM -0700, Jianjun Duan wrote: > Please see comments below: >=20 > On 10/05/2016 03:12 AM, Dr. David Alan Gilbert wrote: > > * Jianjun Duan (duanj@linux.vnet.ibm.com) wrote: > >> In QOM(QEMU Object Model) migrated objects are identified with instanc= e_id > >> which is calculated automatically using their path in the QOM composit= ion > >> tree. For some objects, this path could change from source to target in > >> migration. To migrate such objects, we need to make sure the instance_= id does > >> not change from source to target. We add a hook in DeviceClass to do c= ustomized > >> instance_id calculation in such cases. > >=20 > > Can you explain a bit about why the path changes from source to destina= tion; > > the path here should be a feature of the guest state not the host, and = so I > > don't understand why it changes. > Please see the discussion with David in the previous versions: > http://lists.nongnu.org/archive/html/qemu-ppc/2016-06/msg00062.html Um.. your description above really isn't an accurate summary of that discussion. The point is not that the qom path will vary from source to destination for some arbitrary reason, but rather that we anticipate future changes in the QOM structure. Specifically we're considering eliminating the DRC objects, and folding their (limited) state into an array in the parent object (either the machine or a PCI host bridge). That would change the qom paths, and hence the auto-generated instance ids, which would break migration between qemu versions before and after the restructure. I'm not sure that changing the instance ids is enough though, anyway, since we're talking about eliminating the object entirely, the class/type information in the migration stream also wouldn't match. Dave, if you have ideas on how to deal with that, I'd love to hear them >=20 > >> As a result, in these cases compat will not be set in the concerned > >> SaveStateEntry. This will prevent the inconsistent idstr to be sent ov= er in > >> migration. We could have set alias_id in a similar way. But that will = be > >> overloading the purpose of alias_id. > >> > >> The first application will be setting instance_id for DRC using its un= ique > >> index. Doing this makes the instance_id of DRC to be consistent across= migration > >> and supports flexible management of DRC objects in migration. > >=20 > > Is there a reason to use a custom instance_id rather than a custom idstr >=20 > It can be done either way. But it is easier to deal with a integer than > a string. A bit, but I don't think that's a good enough reason to introduce a second mechanism for overriding instance id allocations. --=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 --/rDaUNvWv5XYRSKj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJX9w5vAAoJEGw4ysog2bOSVAcQAJScnAaz6SumZ6s804ndOAFj 1YuDO1zQfJM1FkwNSTCuPeJQz93ebTnyKb3nyoJlqBiwJEIk46t02O+zJHbaMlJi DqlJje/UmysPND9E+67X8K68slxUCzpuxoNUpw8lvJCCHiFC3JP7E+Z4f+ZZbpcQ zt7VFaduaQxlUNEu1VCgXhlMkBkK+qEXFHj9C/ZCaIrnkM607+xhcmFMt027RJgZ eMpJoOs2KjilGoxKouxrybHkHcI4OtQSQWIE3e/LH8BdGzwRbJJ+cwowEbMrq7MF KBRjqc+q88zFJmF4wSIV3JlgLl1dR0fTYcTXw5grSWihDdWymL9j5eHW+6yQ8n+m TElDFLTGyc/eKrYTw/gHoPlOMgB5XgsCwKPNbiZwvO2yZEvFfjabV7MBUNfI1R30 gbVxyxlxR8yB55h+qekTA2/sYiBl0b7pLl1pRKtDz+DaAN1Hxwwrjr9ZcMudC5UN Jvl8gCRPOmtePZnaU0Fowx28sEUOPua5Uc1cyvL6SwHIjrSMdQIeSvFnz5r3CfUY 7QzjZoWKMgmuicvRi1rr8GK8QCdC9YkAwLDE//+AFsKumsUD4u8QxJjX/MxDPdaH b5Fjzt+cv3wd+E9QgzTn6GxIirwav/epGnDBWCwYZw8xiKEFKlNU4KrsXKC4P1YA FtsgEuhsWBOgwX11xgiJ =mN25 -----END PGP SIGNATURE----- --/rDaUNvWv5XYRSKj--