On Fri, Jan 20, 2012 at 12:13:48PM +0100, Jan Kiszka wrote: > On 2012-01-20 11:25, Daniel P. Berrange wrote: > > On Fri, Jan 20, 2012 at 11:22:27AM +0100, Jan Kiszka wrote: > >> On 2012-01-20 11:14, Marcelo Tosatti wrote: > >>> On Thu, Jan 19, 2012 at 07:01:44PM +0100, Jan Kiszka wrote: > >>>> On 2012-01-19 18:53, Marcelo Tosatti wrote: > >>>>>> What problems does it cause, and in which scenarios? Can't they be > >>>>>> fixed? > >>>>> > >>>>> If the guest compensates for lost ticks, and KVM reinjects them, guest > >>>>> time advances faster then it should, to the extent where NTP fails to > >>>>> correct it. This is the case with RHEL4. > >>>>> > >>>>> But for example v2.4 kernel (or Windows with non-acpi HAL) do not > >>>>> compensate. In that case you want KVM to reinject. > >>>>> > >>>>> I don't know of any other way to fix this. > >>>> > >>>> OK, i see. The old unsolved problem of guessing what is being executed. > >>>> > >>>> Then the next question is how and where to control this. Conceptually, > >>>> there should rather be a global switch say "compensate for lost ticks of > >>>> periodic timers: yes/no" - instead of a per-timer knob. Didn't we > >>>> discussed something like this before? > >>> > >>> I don't see the advantage of a global control versus per device > >>> control (in fact it lowers flexibility). > >> > >> Usability. Users should not have to care about individual tick-based > >> clocks. They care about "my OS requires lost ticks compensation, yes or no". > > > > FYI, at the libvirt level we model policy against individual timers, for > > example: > > > > <clock offset="localtime"> > > <timer name="rtc" tickpolicy="catchup" track="guest"/> > > <timer name="pit" tickpolicy="delay"/> > > </clock> > > Are the various modes of tickpolicy fully specified somewhere? There are some (not all that great) docs here: http://libvirt.org/formatdomain.html#elementsTime The meaning of the 4 policies are: delay: continue to deliver at normal rate catchup: deliver at higher rate to catchup merge: ticks merged into 1 single tick discard: all missed ticks are discarded The original design rationale was here, though beware that some things changed between this design & the actual implementation libvirt has: https://www.redhat.com/archives/libvir-list/2010-March/msg00304.html Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- 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
