[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kv
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics? |
Date: |
Fri, 20 Jan 2012 12:42:48 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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.
> > 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.
That's not a real problem, now I notice they are missing the docs, I
can just add them in.
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 :|
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, (continued)
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Marcelo Tosatti, 2012/01/19
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Jan Kiszka, 2012/01/19
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Marcelo Tosatti, 2012/01/19
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Jan Kiszka, 2012/01/19
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Marcelo Tosatti, 2012/01/20
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Jan Kiszka, 2012/01/20
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Daniel P. Berrange, 2012/01/20
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Jan Kiszka, 2012/01/20
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Daniel P. Berrange, 2012/01/20
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Jan Kiszka, 2012/01/20
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?,
Daniel P. Berrange <=
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Jan Kiszka, 2012/01/20
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Daniel P. Berrange, 2012/01/20
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Jan Kiszka, 2012/01/20
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Daniel P. Berrange, 2012/01/20
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Jamie Lokier, 2012/01/20
- Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics?, Jan Kiszka, 2012/01/20