Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?

[Daniel P. Berrange]

On Fri, Jan 20, 2012 at 01:51:20PM +0100, Jan Kiszka wrote:
> On 2012-01-20 13:42, Daniel P. Berrange wrote:
> > On Fri, Jan 20, 2012 at 01:00:06PM +0100, Jan Kiszka wrote:
> >> 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?
> > 
> > It means that the hypervisor will not attempt to do any compensation,
> > so the guest will see delays in its ticks being delivered & gradually
> > drift over time.
> 
> Still, is the logic as I described? Or what is the difference to "discard".

With 'discard', the delayed tick will be thrown away. In 'delay', the
delayed tick will still be injected to the guest, possibly well after
the intended injection time though, and there will be no attempt to
compensate by speeding up delivery of later ticks.


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 :|