From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33863) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoBVx-0004X1-6J for qemu-devel@nongnu.org; Fri, 20 Jan 2012 05:16:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RoBVq-000752-LG for qemu-devel@nongnu.org; Fri, 20 Jan 2012 05:16:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1025) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoBVq-00074a-As for qemu-devel@nongnu.org; Fri, 20 Jan 2012 05:16:02 -0500 Date: Fri, 20 Jan 2012 08:14:42 -0200 From: Marcelo Tosatti Message-ID: <20120120101441.GA31499@amt.cnet> References: <4F17D56F.9090309@siemens.com> <20120119172532.GC11381@amt.cnet> <4F1854F9.6030400@siemens.com> <20120119175300.GE11381@amt.cnet> <4F185A88.5030904@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F185A88.5030904@siemens.com> 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: Jan Kiszka Cc: qemu-devel , kvm 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). > What about periodic APIC tick compensation? I suppose the kernel does > not support this as no common guest makes use of this as clock source, > right? Recent guests use the APIC timer as clock event, but their time keeping algorithms are not as susceptible to lost ticks as the ones that use PIT/RTC. > Or the HPET? Once the user space model supports compensation, we > need to control it as well. Individually? Ulrich has posted patches for HPET compensation: http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01989.html > I just want to avoid introducing an clumsy interface we then need to > maintain for a long time. > > Jan If the option is a qdev property, i don't see what is clumsy about it?