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

["Daniel P. Berrange" <berrange@redhat.com>]

On Fri, Jan 20, 2012 at 02:02:03PM +0100, Jan Kiszka wrote:
> On 2012-01-20 13:54, Daniel P. Berrange wrote:
> > 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.
> 
> OK, let's see if I got it:
> 
> delay   - all lost ticks are replayed in a row once the guest accepts
>           them again
> catchup - lost ticks are gradually replayed at a higher frequency than
>           the original tick
> merge   - at most one tick is replayed once the guest accepts it again
> discard - no lost ticks compensation

Yes, I think that is a good understanding.

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