* 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