From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49045) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1Sc8-0008CL-JM for qemu-devel@nongnu.org; Thu, 29 Mar 2018 04:08:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1Sc7-0007I2-QV for qemu-devel@nongnu.org; Thu, 29 Mar 2018 04:08:52 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:57620 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f1Sc7-0007HP-Lf for qemu-devel@nongnu.org; Thu, 29 Mar 2018 04:08:51 -0400 Date: Thu, 29 Mar 2018 09:08:46 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20180329080846.GA2982@work-vm> References: <20180328163630.48576-1-dgilbert@redhat.com> <20180328163630.48576-6-dgilbert@redhat.com> <780d6d45-84a6-34db-e65f-3d38a6d0ea66@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <780d6d45-84a6-34db-e65f-3d38a6d0ea66@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 5/6] e1000: Choose which set of props to migrate List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang Cc: qemu-devel@nongnu.org, eswierk@skyportsystems.com, pbonzini@redhat.com, peterx@redhat.com, quintela@redhat.com * Jason Wang (jasowang@redhat.com) wrote: >=20 >=20 > On 2018=E5=B9=B403=E6=9C=8829=E6=97=A5 00:36, Dr. David Alan Gilbert (g= it) wrote: > > From: "Dr. David Alan Gilbert" > >=20 > > When we're using the subsection we migrate both > > the 'props' and 'tso_props' data; when we're not using > > the subsection (to migrate to 2.11 or old machine types) we've > > got to choose what to migrate in the main structure. > >=20 > > If we're using the subsection migrate 'props' in the main structure. > > If we're not using the subsection then migrate the last one > > that changed, which gives behaviour similar to the old behaviour. > >=20 > >=20 >=20 > But only after migration. Why not simply switch back to the old behavio= r if > migrate_tso_props if false? Because: 1) We know it's a broken behaviour so it's better not to unfix it 2) The fix doesn't change guest visible behaviour other than actually sending the right packets; so there's no reason to make the fix itself dependent on the machine type. 3) Gating the fix itself on the flag is actually more complex and would need checking the flag in lots of places that are already pretty complex, rather than what this does which is just check it in one place at migration. Dave > Thanks >=20 -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK