Re: [PATCH 0/4] Avoid soft lockup message when KVM is stopped by host

[Marcelo Tosatti <mtosatti@redhat.com>]

On Tue, Aug 30, 2011 at 09:43:19AM -0500, Ryan Harper wrote:
> * Marcelo Tosatti <mtosatti@redhat.com> [2011-08-30 09:40]:
> > On Tue, Aug 30, 2011 at 09:12:17AM -0500, Ryan Harper wrote:
> > > * Marcelo Tosatti <mtosatti@redhat.com> [2011-08-30 07:35]:
> > > > On Mon, Aug 29, 2011 at 05:27:11PM -0600, Eric B Munson wrote:
> > > > > Currently, when qemu stops a guest kernel that guest will issue a soft lockup
> > > > > message when it resumes.  This set provides the ability for qemu to comminucate
> > > > > to the guest that it has been stopped.  When the guest hits the watchdog on
> > > > > resume it will check if it was suspended before issuing the warning.
> > > > > 
> > > > > Eric B Munson (4):
> > > > >   Add flag to indicate that a vm was stopped by the host
> > > > >   Add functions to check if the host has stopped the vm
> > > > >   Add generic stubs for kvm stop check functions
> > > > >   Add check for suspended vm in softlockup detector
> > > > > 
> > > > >  arch/x86/include/asm/pvclock-abi.h |    1 +
> > > > >  arch/x86/include/asm/pvclock.h     |    2 ++
> > > > >  arch/x86/kernel/kvmclock.c         |   14 ++++++++++++++
> > > > >  include/asm-generic/pvclock.h      |   14 ++++++++++++++
> > > > >  kernel/watchdog.c                  |   12 ++++++++++++
> > > > >  5 files changed, 43 insertions(+), 0 deletions(-)
> > > > >  create mode 100644 include/asm-generic/pvclock.h
> > > > > 
> > > > > -- 
> > > > > 1.7.4.1
> > > > 
> > > > How is the host supposed to set this flag? 
> > > > 
> > > > As mentioned previously, if you save save/restore the offset added to
> > > > kvmclock on stop/cont (and the TSC MSR, forgot to mention that), no
> > > > paravirt infrastructure is required. Which means the issue is also fixed
> > > > for older guests.
> > > 
> > > How is saving the offset going to prevent a large jump from triggering
> > > the softlock message?  Won't we still have not touched the watchdog for
> > > that long period of time?
> > 
> > The idea is to adjust the offset and the TSC value so that the guest
> > does not notice the actual elapsed time. This is what happens when a
> > guest is migrated or saved/restore, for example.
> 
> but that's within a rather short period of time... if we stop the guest
> for a day, I don't think what you are suggesting can happen without time
> being wrong in the guest, 

Right.

> and as soon as it's corrected and we jump forward larger than the
> watchdog timeout, won't we trigger it again?

The time correction within the guest happens separately from the
kvmclock clocksource, so no, watchdog timeout will not trigger.