Re: [Qemu-devel] [PATCH] eepro100: Fix memory leak and simplify code for VMStateDescription

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* 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