From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH 3/3] stop the periodic RTC update timer Date: Thu, 12 Jan 2012 11:43:10 +0100 Message-ID: <4F0EB93E.9090908@redhat.com> References: <20120111131004.GA18178@amt.cnet> <4F0EA739.1040707@redhat.com> <20120112102031.GA31635@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:8386 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751153Ab2ALKnN (ORCPT ); Thu, 12 Jan 2012 05:43:13 -0500 In-Reply-To: <20120112102031.GA31635@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: 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