From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bxUqU-0004St-O3 for qemu-devel@nongnu.org; Fri, 21 Oct 2016 04:06:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bxUqP-0002zg-8U for qemu-devel@nongnu.org; Fri, 21 Oct 2016 04:06:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46432) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bxUqO-0002yc-V1 for qemu-devel@nongnu.org; Fri, 21 Oct 2016 04:06:25 -0400 Date: Fri, 21 Oct 2016 09:06:18 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20161021080617.GA2039@work-vm> References: <1476380759-18492-1-git-send-email-sw@weilnetz.de> <20161014082539.GA2030@work-vm> <20161017090116.GA2042@work-vm> <7edecc2d-b4f0-27df-9cb2-7780189afe97@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7edecc2d-b4f0-27df-9cb2-7780189afe97@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] eepro100: Fix memory leak and simplify code for VMStateDescription List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang Cc: Stefan Weil , QEMU Developer , amit.shah@redhat.com, Li Qiang , Juan Quintela * Jason Wang (jasowang@redhat.com) wrote: >=20 >=20 > On 2016=E5=B9=B410=E6=9C=8817=E6=97=A5 17:01, Dr. David Alan Gilbert wr= ote: > > * Stefan Weil (sw@weilnetz.de) wrote: > > > On 10/14/16 10:25, Dr. David Alan Gilbert wrote: > > > > * Stefan Weil (sw@weilnetz.de) wrote: > > > > > Instead of allocating a VMStateDescription for each NIC instanc= e, > > > > > the code now uses a single constant VMStateDescription for all > > > > > instances. That implies that the name field is always the same. > > > > Doesn't this break migration compatibility? > > > >=20 > > > > You might be able to get around that (in the forward direction on= ly) > > > > by adding an entry to qdev_alias_table but I'm not sure. > > > >=20 > > > > Dave > > > I'm not an expert for migration (never used it myself). > > >=20 > > > Is migration compatibility a must, even for non default settings > > > like the NICs implemented by eepro100.c? I assume that applications > > > which use migration will usually run with an e1000 NIC. > > >=20 > > > Or can we break migration compatibility and add that information > > > to the release notes? > > We normally keep migration compatibility for all devices > > in the forward direction unless it's something really obscure; > > I don't think an e100 is. > >=20 > > > How does e1000 handle migration if QEMU was started with a > > > e1000-82544gc NIC and migrated to a e1000-82545em NIC? > > That's not required to work; you're required to have the same device > > configuration on the destination as the source. > >=20 > > $ qemu-system-x86_64 -nographic -device e1000-82544gc > > (qemu) migrate "exec:cat > t.mig" > >=20 > > $ qemu-system-x86_64 -nographic -device e1000-82545em -incoming "exec= :cat t.mig" > > qemu-system-x86_64: get_pci_config_device: Bad config data: i=3D0x2 r= ead: c device: f cmask: ff wmask: 0 w1cmask:0 > > qemu-system-x86_64: error while loading state for instance 0x0 of dev= ice '0000:00:04.0/e1000' > > qemu-system-x86_64: load of migration failed: Invalid argument > >=20 > > Now, note that what's happening here is that e1000 is doing a similar > > trick to what you're doing - i.e. all devices end up getting > > migrated as 'e1000' in the device string (0000:00:04.0/e1000). > >=20 > > The scheme you end up with is OK, but the problem is it's just > > different from what we have now, so existing streams > > with device names like '0000:00:04.0/i82550' won't load. > >=20 > > Dave > >=20 >=20 > Can we bump the version here? Or just use v1 for the fixing. The problem isn't the version of the contents of the section, it's the naming of the devices. I think you can work around it by adding aliases for the old names. Dave > Thanks -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK