On 2012-01-20 12:45, Daniel P. Berrange wrote: > 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 What does this mean? The timer stops ticking until the guest accepts its ticks again? > catchup: deliver at higher rate to catchup > merge: ticks merged into 1 single tick > discard: all missed ticks are discarded But those interpretations aren't stated in the docs. That makes it hard to map them on individual hypervisors - or model proper new hypervisor interfaces accordingly. > > > 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 Given that there is almost no tick compensation in QEMU yet (ignoring the awful RTC hack for now), this is a good time to establish a useful generic interface with the advent of the KVM device models. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
