From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoDzT-0003EO-Io for qemu-devel@nongnu.org; Fri, 20 Jan 2012 07:54:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RoDzN-0000YU-Mf for qemu-devel@nongnu.org; Fri, 20 Jan 2012 07:54:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:27816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoDzN-0000XP-FT for qemu-devel@nongnu.org; Fri, 20 Jan 2012 07:54:41 -0500 Date: Fri, 20 Jan 2012 12:54:34 +0000 From: "Daniel P. Berrange" Message-ID: <20120120125434.GG28798@redhat.com> References: <20120119175300.GE11381@amt.cnet> <4F185A88.5030904@siemens.com> <20120120101441.GA31499@amt.cnet> <4F194063.60307@siemens.com> <20120120102549.GB28798@redhat.com> <4F194C6C.1070603@siemens.com> <20120120114517.GC28798@redhat.com> <4F195746.1010403@siemens.com> <20120120124248.GD28798@redhat.com> <4F196348.1090303@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F196348.1090303@siemens.com> Subject: Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics? Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Marcelo Tosatti , qemu-devel , kvm 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: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> 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 :|