From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoDwF-00022j-LE for qemu-devel@nongnu.org; Fri, 20 Jan 2012 07:51:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RoDwE-0008Vl-8N for qemu-devel@nongnu.org; Fri, 20 Jan 2012 07:51:27 -0500 Received: from goliath.siemens.de ([192.35.17.28]:33005) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoDwD-0008VZ-R7 for qemu-devel@nongnu.org; Fri, 20 Jan 2012 07:51:26 -0500 Message-ID: <4F196348.1090303@siemens.com> Date: Fri, 20 Jan 2012 13:51:20 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20120119172532.GC11381@amt.cnet> <4F1854F9.6030400@siemens.com> <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> In-Reply-To: <20120120124248.GD28798@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu-kvm upstreaming: Do we need -no-kvm-pit and -no-kvm-pit-reinjection semantics? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Marcelo Tosatti , qemu-devel , kvm 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". > >>> 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. TIA, but just please more verbose. The above descriptions only help if you take real implementations of hypervisors as reference. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux