From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60945) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoBcI-00061m-4o for qemu-devel@nongnu.org; Fri, 20 Jan 2012 05:22:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RoBc9-0000BM-6o for qemu-devel@nongnu.org; Fri, 20 Jan 2012 05:22:42 -0500 Received: from goliath.siemens.de ([192.35.17.28]:21043) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RoBc8-0000B3-U2 for qemu-devel@nongnu.org; Fri, 20 Jan 2012 05:22:33 -0500 Message-ID: <4F194063.60307@siemens.com> Date: Fri, 20 Jan 2012 11:22:27 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4F17D56F.9090309@siemens.com> <20120119172532.GC11381@amt.cnet> <4F1854F9.6030400@siemens.com> <20120119175300.GE11381@amt.cnet> <4F185A88.5030904@siemens.com> <20120120101441.GA31499@amt.cnet> In-Reply-To: <20120120101441.GA31499@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1 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: Marcelo Tosatti Cc: qemu-devel , kvm 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". Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux