From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] [PATCH 1/2] KVM: fix i8259 interrupt high to low transition logic Date: Thu, 13 Sep 2012 15:49:36 +0200 Message-ID: <5051E470.8080006@siemens.com> References: <1347240563-6212-1-git-send-email-mmogilvi_qemu@miniinfo.net> <50504151.40704@redhat.com> <50504C69.60703@siemens.com> <50504D2E.2080802@redhat.com> <50504E95.9040709@siemens.com> <20120913054950.GA4717@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Matthew Ogilvie , Avi Kivity , "qemu-devel@nongnu.org" , Paolo Bonzini , "kvm@vger.kernel.org" To: "Maciej W. Rozycki" Return-path: Received: from goliath.siemens.de ([192.35.17.28]:23353 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750754Ab2IMNto (ORCPT ); Thu, 13 Sep 2012 09:49:44 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 2012-09-13 15:41, Maciej W. Rozycki wrote: > On Wed, 12 Sep 2012, Matthew Ogilvie wrote: > >> Also, how big of a concern is a very rare gained or lost IRQ0 >> actually? Under normal conditions, I would expect this to at most >> cause a one time clock drift in the guest OS of a fraction of >> a second. If that only happens when rebooting or migrating the >> guest... > > It depends on how you define "very rare". Once per month or probably > even per day is probably acceptable although you'll see a disruption in > the system clock. This is still likely unwanted if the system is used as > a clock reference and not just wants to keep its clock right for own > purposes. Anything more frequent and NTP does care very much; an accurate > system clock is important in many uses, starting from basic ones such as > where timestamps of files exported over NFS are concerned. > > Speaking of real hw -- I don't know whether that really matters for > emulated systems. Thanks for looking into the 8254 PIT in details. First correct, then fast. That rule applies at least to the conceptual phase. Also, for rarely used PIT modes, I would refrain from optimizing them away from the specified behaviour. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59638) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TC9nf-0005ro-HZ for qemu-devel@nongnu.org; Thu, 13 Sep 2012 09:49:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TC9nZ-0002uD-Os for qemu-devel@nongnu.org; Thu, 13 Sep 2012 09:49:47 -0400 Received: from goliath.siemens.de ([192.35.17.28]:16989) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TC9nZ-0002u5-F0 for qemu-devel@nongnu.org; Thu, 13 Sep 2012 09:49:41 -0400 Message-ID: <5051E470.8080006@siemens.com> Date: Thu, 13 Sep 2012 15:49:36 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1347240563-6212-1-git-send-email-mmogilvi_qemu@miniinfo.net> <50504151.40704@redhat.com> <50504C69.60703@siemens.com> <50504D2E.2080802@redhat.com> <50504E95.9040709@siemens.com> <20120913054950.GA4717@comcast.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] KVM: fix i8259 interrupt high to low transition logic List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Maciej W. Rozycki" Cc: "qemu-devel@nongnu.org" , Paolo Bonzini , Matthew Ogilvie , "kvm@vger.kernel.org" , Avi Kivity On 2012-09-13 15:41, Maciej W. Rozycki wrote: > On Wed, 12 Sep 2012, Matthew Ogilvie wrote: > >> Also, how big of a concern is a very rare gained or lost IRQ0 >> actually? Under normal conditions, I would expect this to at most >> cause a one time clock drift in the guest OS of a fraction of >> a second. If that only happens when rebooting or migrating the >> guest... > > It depends on how you define "very rare". Once per month or probably > even per day is probably acceptable although you'll see a disruption in > the system clock. This is still likely unwanted if the system is used as > a clock reference and not just wants to keep its clock right for own > purposes. Anything more frequent and NTP does care very much; an accurate > system clock is important in many uses, starting from basic ones such as > where timestamps of files exported over NFS are concerned. > > Speaking of real hw -- I don't know whether that really matters for > emulated systems. Thanks for looking into the 8254 PIT in details. First correct, then fast. That rule applies at least to the conceptual phase. Also, for rarely used PIT modes, I would refrain from optimizing them away from the specified behaviour. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux