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

[Dr. David Alan Gilbert]

* Jason Wang (address@hidden) wrote:
> 
> 
> On 2016年10月17日 17:01, Dr. David Alan Gilbert wrote:
> > * Stefan Weil (address@hidden) wrote:
> > > On 10/14/16 10:25, Dr. David Alan Gilbert wrote:
> > > > * Stefan Weil (address@hidden) 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
> > 
> 
> 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 / address@hidden / Manchester, UK