From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44182) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoEAz-0006Z4-Fk for qemu-devel@nongnu.org; Fri, 20 Jan 2012 08:06:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RoEAs-0002ce-M1 for qemu-devel@nongnu.org; Fri, 20 Jan 2012 08:06:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:24444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoEAs-0002ca-BB for qemu-devel@nongnu.org; Fri, 20 Jan 2012 08:06:34 -0500 Date: Fri, 20 Jan 2012 13:06:29 +0000 From: "Daniel P. Berrange" Message-ID: <20120120130628.GI28798@redhat.com> References: <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> <20120120125434.GG28798@redhat.com> <4F1965CB.6020706@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F1965CB.6020706@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 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: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> 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 :|