[Qemu-devel] Re: [PATCH] rtl8139: IO memory is not part of vmstate

[Alex Williamson]

On Tue, 2010-12-14 at 06:43 +0200, Michael S. Tsirkin wrote:
> On Mon, Dec 13, 2010 at 12:15:08PM -0700, Alex Williamson wrote:
> > On Mon, 2010-12-13 at 21:06 +0200, Michael S. Tsirkin wrote:
> > > On Mon, Dec 13, 2010 at 11:59:16AM -0700, Alex Williamson wrote:
> > > > On Mon, 2010-12-13 at 20:54 +0200, Michael S. Tsirkin wrote:
> > > > > On Mon, Dec 13, 2010 at 11:00:44AM -0700, Alex Williamson wrote:
> > > > > > On Mon, 2010-12-13 at 19:50 +0200, Michael S. Tsirkin wrote:
> > > > > > > On Mon, Dec 13, 2010 at 10:43:22AM -0700, Alex Williamson wrote:
> > > > > > > > So, unfortunately, I stand by my original patch.
> > > > > > > 
> > > > > > > What about the one that put -1 in saved index for a hotplugged 
> > > > > > > device?
> > > > > > 
> > > > > > There are still examples that don't work even without hotplug 
> > > > > > (example 2
> > > > > > and example 3 after the reboot).  That hack limits the damage, but 
> > > > > > still
> > > > > > leaves a latent bug for reboot and doesn't address the non-hotplug
> > > > > > scenarios.  So, I don't think it's worthwhile to pursue, and we
> > > > > > shouldn't pretend we can use it to avoid bumping the version_id.
> > > > > > Thanks,
> > > > > > 
> > > > > > Alex
> > > > > 
> > > > > I guess when we bump it we tell users: migration is completely
> > > > > borken to the old version, don't even try it.
> > > > > 
> > > > > Is there a way for libvirt to discover such incompatibilities
> > > > > and avoid the migration?
> > > > 
> > > > I don't know if libvirt has a way to query this in advance.  If a
> > > > migration is attempted, the target will report:
> > > > 
> > > > savevm: unsupported version 5 for '0000:00:03.0/rtl8139' v4
> > > > 
> > > > And the source will continue running.  We waste plenty of bits getting
> > > > to that point,
> > > 
> > > Yes, this happens after all of memory has been migrated.
> > 
> > Better late than never :^\
> 
> One other question: can we do the same by creating a new (empty)
> section? As was discussed in the past this is easier for
> downstreams to cherry-pick.

The only way I can think to do that would be to have a subsection that
is always included, but saves no data.  That would force a failure on
new->old migration, but I don't think it really matches the intended
purpose of subsections and feels like it's adding cruft for no gain.
Maybe I'm missing something.  Juan, is there any advantage to trapping
this in a subsection?  Thanks,

Alex