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

[Antoine Damhet]

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
```

# 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

signature.asc
Description: PGP signature