From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RlI7y-0001cG-2C for qemu-devel@nongnu.org; Thu, 12 Jan 2012 05:43:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RlI7l-0005bP-V5 for qemu-devel@nongnu.org; Thu, 12 Jan 2012 05:43:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34393) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RlI7l-0005bK-ON for qemu-devel@nongnu.org; Thu, 12 Jan 2012 05:43:13 -0500 Message-ID: <4F0EB93E.9090908@redhat.com> Date: Thu, 12 Jan 2012 11:43:10 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20120111131004.GA18178@amt.cnet> <4F0EA739.1040707@redhat.com> <20120112102031.GA31635@amt.cnet> In-Reply-To: <20120112102031.GA31635@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] stop the periodic RTC update timer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 01/12/2012 11:20 AM, Marcelo Tosatti wrote: >> > >> > The point is not_correctness_. It is_atomicity_. > Quoting you earlier > > "This is incorrect, for two reasons. First, the UIP is in the spec, > and we have to implement it. Second, reading the clock is not atomic, > and waiting for UIP=0 gives you 220 microseconds during which you know > that the read will appear atomic." (The actual figure is 244, not 220; my mistake). > Agree with the first point, but the second, the emulated RTC never > returns a bogus read. That's true: the update cycle takes 1984 us on the real RTC, and 0 us on QEMU. However, the data sheet says that the update cycle begins 244 us _after_ the rising edge of UIP. In other words, UIP is set for 1984 + 244 us on the real RTC, and should be set for 0 + 244 us on the emulated RTC. This is done on purpose: the data sheet says, "if a low is read on the UIP bit, the user has at least 244 us before the time/calendar data will be changed". As long as you read the time within 244 us, the following cannot happen: read UIP => 0 read HOURS => 10 read MINUTES => 59 read SECONDS => 59 ... read UIP => 0 read HOURS => 10 read MINUTES => 59 update happens! (on real RTC: update cycle starts) read SECONDS => 0 (on real RTC: undefined) You are a kernel junkie and as such you are too much accustomed to seqlocks. ;) If you know the read will take more than 244 us, the data sheet suggests that you use the update-ended interrupt. But you can also wait for the falling edge of UIP, like Xen does. The falling edge of UIP will never happen if the emulated RTC always returns 0 for UIP. Paolo