qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 8/9] static checker: e1000-82540em got aliased to


From: Amit Shah
Subject: Re: [Qemu-devel] [PULL 8/9] static checker: e1000-82540em got aliased to e1000
Date: Mon, 22 Feb 2016 18:09:40 +0530

On (Thu) 11 Feb 2016 [14:04:06], Paolo Bonzini wrote:
> 
> 
> On 05/02/2016 14:56, Amit Shah wrote:
> > Commit 8304402033e8dbe8e379017d51ed1dd8344f1dce changed the name of the
> > e1000-82540em device to e1000.  This was flagged:
> > 
> >    Section "e1000-82540em" does not exist in dest
> > 
> > Add the mapping to the changed section names dictionary so the checker
> > can proceed.
> > 
> > Signed-off-by: Amit Shah <address@hidden>
> > Acked-by: Jason Wang <address@hidden>
> > Message-Id: <address@hidden>
> > Signed-off-by: Amit Shah <address@hidden>
> > ---
> >  scripts/vmstate-static-checker.py | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/scripts/vmstate-static-checker.py 
> > b/scripts/vmstate-static-checker.py
> > index b6c0bbe..b5ecaf6 100755
> > --- a/scripts/vmstate-static-checker.py
> > +++ b/scripts/vmstate-static-checker.py
> > @@ -99,6 +99,7 @@ def get_changed_sec_name(sec):
> >      # Section names can change -- see commit 292b1634 for an example.
> >      changes = {
> >          "ICH9 LPC": "ICH9-LPC",
> > +        "e1000-82540em": "e1000",
> >      }
> >  
> >      for item in changes:
> > 
> 
> This means that 2.5 cannot migrate 2.4 virtual machines, right?  Is that
> something we want to rectify in 2.6 by making e1000-82540em an alias of
> e1000 (instead of the other way round)?

You're right; I misread it.  With that commit (8304402033):

2.4 with e1000-82540em will not migrate to 2.5 with e1000-82540em.

This is despite they're aliased (so the cmdline is backward
compatible), but the migration device name actually changed.

Of course, 2.5->2.4 will also not work.

Since 2.4 emits 'e1000-82540em' as the device name in the migration
stream, and 2.5 emits just 'e1000', we have two different names for
the same device in two versions.

To fix this, we'll need a hack on the dest side to allow e1000 and
e1000-82540em in the migration stream for the device, and this can be
done for 2.6 and 2.5.stable.

Jason, can you attempt this?


                Amit



reply via email to

[Prev in Thread] Current Thread [Next in Thread]