Re: [PATCH] target/i386: always create kvmclock device

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Antoine Damhet (antoine.damhet@blade-group.com) wrote:
> On Thu, Sep 17, 2020 at 06:44:10PM +0100, Dr. David Alan Gilbert wrote:
> 
> [...]
> 
> > > >> >
> > > >> > Shouldn't the old check used when machine type <= 5.1 in order to avoid
> > > >> > migration incompatibility ?
> > > >> 
> > > >> Hm, when the check fails we just don't create the device and no error is
> > > >> reported, so even if we have kvmclock data in the migration stream but
> > > >> fail to create it migration will still succeed, right? (not a migration
> > > >> expert here :-)
> > > >
> > > > When the migration stream is parsed, it'll try and find a "kvmclock"
> > > > device to pass the data it's reading to; if one doesn't exist it'll
> > > > fail.
> > > 
> > > This may happen with an older machine type when the destination is
> > > running an unfixed QEMU and the source has the fix, right?
> > 
> > Yes I think so.
> > 
> > > The solution
> > > would be to introduce a flag for older machine types (or for new ones)
> > > like 'kvmclock_always'.
> > 
> > Yep sounds the normal answer.
> > (You might want to try it first to trigger the bug)
> 
> So, I tried the patch and:
> 
> # patched -> patched
> 
> Everything working as expected
> 
> # patched -> unpatched
> 
> Migration failure with:
> 
> ```
> Unknown savevm section or instance 'kvmclock' 0. Make sure that your current VM setup matches your saved VM setup, including any hotplugged devices
> load of migration failed: Invalid argument
> ```

Right, that's what I expected and said we need to wire this fix to the
machine type.

Dave

> 
> # unpatched -> patched
> 
> The guest hangs upon arrival, I don't know which value is restored but
> something is restored (and far enough from 0 to confuse Windows).
> 
> > 
> > > > The other question is in the incoming direction from an older VM;
> > > > you'll have a kvm clock created here, but you won't load the kvm clock
> > > > state from the migration stream - what is this clock going to do?
> > > 
> > > This is not really a problem I believe: the clock was absent on the
> > > source and things somehow worked for the guest so even if we don't
> > > initialize kvmclock properly on the destination nothing bad is expected.
> > 
> > OK.
> > 
> > Dave
> 
> [...]
> 
> -- 
> Antoine 'xdbob' Damhet


-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK