All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Stefan Weil <sw@weilnetz.de>,
	QEMU Developer <qemu-devel@nongnu.org>,
	amit.shah@redhat.com, Li Qiang <liqiang6-s@360.cn>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] eepro100: Fix memory leak and simplify code for VMStateDescription
Date: Fri, 21 Oct 2016 09:06:18 +0100	[thread overview]
Message-ID: <20161021080617.GA2039@work-vm> (raw)
In-Reply-To: <7edecc2d-b4f0-27df-9cb2-7780189afe97@redhat.com>

* Jason Wang (jasowang@redhat.com) wrote:
> 
> 
> On 2016年10月17日 17:01, Dr. David Alan Gilbert wrote:
> > * 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
> > 
> 
> 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

  reply	other threads:[~2016-10-21  8:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-13 17:45 [Qemu-devel] [PATCH] eepro100: Fix memory leak and simplify code for VMStateDescription Stefan Weil
2016-10-14  8:25 ` Dr. David Alan Gilbert
2016-10-15  5:35   ` Stefan Weil
2016-10-17  9:01     ` Dr. David Alan Gilbert
2016-10-21  1:53       ` Jason Wang
2016-10-21  8:06         ` Dr. David Alan Gilbert [this message]
2016-10-21 19:25           ` Stefan Weil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161021080617.GA2039@work-vm \
    --to=dgilbert@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=liqiang6-s@360.cn \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=sw@weilnetz.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.