From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzjhe-0003UV-Ud for qemu-devel@nongnu.org; Thu, 27 Oct 2016 08:22:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzjha-0007Mh-6S for qemu-devel@nongnu.org; Thu, 27 Oct 2016 08:22:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38908) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bzjha-0007ME-12 for qemu-devel@nongnu.org; Thu, 27 Oct 2016 08:22:34 -0400 Date: Thu, 27 Oct 2016 13:22:29 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20161027122228.GC2033@work-vm> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20161027113909.GG5057@thinpad.lan.raisama.net> 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: Eduardo Habkost Cc: Dmitry Fleytman , Jason Wang , qemu-devel@nongnu.org * 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). Without knowing the e1000e code, isn't the easy way to do this to change the: VMSTATE_UINT16(subsys, E1000EState), VMSTATE_UINT16(subsys_ven, E1000EState), to VMSTATE_UINT16_EQUAL(subsys, E1000EState), VMSTATE_UINT16_EQUAL(subsys_ven, E1000EState), and the migration code will flag if they don't match for you. Dave >=20 > --=20 > Eduardo >=20 -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK