From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54912) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzlf6-0005aD-Tv for qemu-devel@nongnu.org; Thu, 27 Oct 2016 10:28:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzlf1-0007yU-9w for qemu-devel@nongnu.org; Thu, 27 Oct 2016 10:28:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43110) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bzlf1-0007yM-4O for qemu-devel@nongnu.org; Thu, 27 Oct 2016 10:28:03 -0400 Date: Thu, 27 Oct 2016 12:28:00 -0200 From: Eduardo Habkost Message-ID: <20161027142800.GH5057@thinpad.lan.raisama.net> References: <1477509718-6969-1-git-send-email-ehabkost@redhat.com> <1477509718-6969-3-git-send-email-ehabkost@redhat.com> <20161027113909.GG5057@thinpad.lan.raisama.net> <20161027122228.GC2033@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20161027122228.GC2033@work-vm> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/4] e1000e: No need to validate configuration on migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Dmitry Fleytman , Jason Wang , qemu-devel@nongnu.org On Thu, Oct 27, 2016 at 01:22:29PM +0100, Dr. David Alan Gilbert wrote: > * Eduardo Habkost (ehabkost@redhat.com) wrote: > > On Thu, Oct 27, 2016 at 09:42:53AM +0300, Dmitry Fleytman wrote: > > >=20 > > > > On 26 Oct 2016, at 22:21 PM, Eduardo Habkost wrote: > > > >=20 > > > > The user (or management software) is responsible for keeping the > > > > same configuration on both sides while migrating. Remove the > > > > configuration validation code at e1000e_post_load, and the > > > > unnecessary subsys_used/subsys_ven_used fields. > > >=20 > > > Migration with different subsys/subsys_ven may have a > > > really cumbersome consequences that are very hard to debug, > > > so I believe such a verification may save a lot of time, > > > however it=E2=80=99s a matter of convention. > >=20 > > The same issues apply to almost every other property on every > > other device. But the convention is to not expect devices to > > validate configuration changes on migration. > >=20 > > (It would be nice to have a more generic mechanism that detects > > configuration mismatch on migration, though. Having each device > > manually checking each of its properties wouldn't work). >=20 > Without knowing the e1000e code, isn't the easy way to do this > to change the: >=20 > VMSTATE_UINT16(subsys, E1000EState), > VMSTATE_UINT16(subsys_ven, E1000EState), > to >=20 > VMSTATE_UINT16_EQUAL(subsys, E1000EState), > VMSTATE_UINT16_EQUAL(subsys_ven, E1000EState), >=20 > and the migration code will flag if they don't match for you. That's very useful. I didn't know about it. I will submit a new version of the series that uses VMSTATE_UINT16_EQUAL. --=20 Eduardo