From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41014) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bw3nT-0006Rn-Gl for qemu-devel@nongnu.org; Mon, 17 Oct 2016 05:01:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bw3nP-00070I-EG for qemu-devel@nongnu.org; Mon, 17 Oct 2016 05:01:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60530) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bw3nP-000703-99 for qemu-devel@nongnu.org; Mon, 17 Oct 2016 05:01:23 -0400 Date: Mon, 17 Oct 2016 10:01:16 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20161017090116.GA2042@work-vm> References: <1476380759-18492-1-git-send-email-sw@weilnetz.de> <20161014082539.GA2030@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Stefan Weil Cc: QEMU Developer , amit.shah@redhat.com, Jason Wang , Li Qiang , Juan Quintela * 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 instance, > > > 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? > > > > You might be able to get around that (in the forward direction only) > > by adding an entry to qdev_alias_table but I'm not sure. > > > > Dave > > I'm not an expert for migration (never used it myself). > > 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. > > 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. > 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. $ qemu-system-x86_64 -nographic -device e1000-82544gc (qemu) migrate "exec:cat > t.mig" $ 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=0x2 read: c device: f cmask: ff wmask: 0 w1cmask:0 qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:04.0/e1000' qemu-system-x86_64: load of migration failed: Invalid argument 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). 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. Dave > > Stefan > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK