On Tue, Sep 20, 2011 at 09:03:51PM +0100, Jamie Lokier wrote: > Marcelo Tosatti wrote: > > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
