From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics? Date: Fri, 20 Jan 2012 14:02:03 +0100 Message-ID: <4F1965CB.6020706@siemens.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> <20120120125434.GG28798@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , qemu-devel , kvm To: "Daniel P. Berrange" Return-path: Received: from goliath.siemens.de ([192.35.17.28]:21329 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752608Ab2ATNCL (ORCPT ); Fri, 20 Jan 2012 08:02:11 -0500 In-Reply-To: <20120120125434.GG28798@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux