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

On Tue, Sep 20, 2011 at 09:03:51PM +0100, Jamie Lokier wrote:

Marcelo Tosatti wrote:

quoted

In case the VM stops for whatever reason, the host system is not
supposed to adjust time related hardware state to compensate, in an
attempt to present apparent continuous time.

If you save a VM and then restore it later, it is the guest
responsability to adjust its time representation.

If the guest doesn't know it's been stopped, then its time
representation will be wrong until it finds out, e.g. after a few
minutes with NTP, or even a seconds can be too long.

That is sad when it happens because it breaks the coherence of any
timed-lease caching the guest is involved in.  I.e. where the guest
acquires a lock on some data object (like a file in NFS) that it can
efficiently access without network round trips (similar to MESI), with
all nodes having agreed that it's coherent for, say, 5 seconds before
renewing or breaking.  (It's just a way to reduce latency.)

But we can't trust CLOCK_MONOTONIC when a VM is involved, it's just
one of those facts of life.  So instead the effort is to try and
detect when a VM is involved and then distrust the clock.

(Non-VM) suspend/resume is similar, but there's usually a way to
be notified about that as it happens.

-- Jamie

Thats pretty bad.

Time leased caching cannot be enabled in conjunction with save/restore
without VM involvement (the hypervisor management application must
notify the guest so it can drop such cache/writeback pending data).

But, if paravirtual clock is available (Linux VMs), it should be
possible to add an offset similarly to how suspend/resume is performed,
via a high priority channel, before resuming operation. We should look
into that possibility.

Thanks