From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36673) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rl1dc-0006rL-6G for qemu-devel@nongnu.org; Wed, 11 Jan 2012 12:07:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rl1dU-0003gg-4f for qemu-devel@nongnu.org; Wed, 11 Jan 2012 12:07:00 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:49635) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rl1dT-0003g0-Pn for qemu-devel@nongnu.org; Wed, 11 Jan 2012 12:06:52 -0500 Received: by iagw33 with SMTP id w33so1623150iag.4 for ; Wed, 11 Jan 2012 09:06:50 -0800 (PST) Message-ID: <4F0DC1A6.7000605@codemonkey.ws> Date: Wed, 11 Jan 2012 11:06:46 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1326222656-26588-1-git-send-email-aliguori@us.ibm.com> <1326222656-26588-15-git-send-email-aliguori@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 15/15] qtest: add rtc-test test-case List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org On 01/10/2012 01:59 PM, Paolo Bonzini wrote: > On 01/10/2012 08:10 PM, Anthony Liguori wrote: >> + sec = cmos_read(0x00); >> + min = cmos_read(0x02); >> + hour = cmos_read(0x04); >> + mday = cmos_read(0x07); >> + mon = cmos_read(0x08); >> + year = cmos_read(0x09); > > Please use identifiers for register numbers. > >> + /* >> + * This check assumes a few things. First, we cannot guarantee that we get >> + * a consistent reading from the wall clock because we may hit an edge of >> + * the clock while reading. To work around this, we read four clock readings >> + * such that at least two of them should match. We need to assume that one >> + * reading is corrupt so we need four readings to ensure that we have at >> + * least two consecutive identical readings >> + * >> + * It's also possible that we'll cross an edge reading the host clock so >> + * simply check to make sure that the clock reading is within the period of >> + * when we expect it to be. >> + */ > > This seems broken to me. It's not broken, although it may be ugly. > The right thing to do would be to run the test with > vm_clock for the rtc_clock, add a way for the qtest machine to bump the vm_clock > to the next event, I actually was looking at this yesterday. Just bumping to the next event is not enough, you want to be able to control how time progresses. I was thinking of adding another qtest_clock and allowing the rtc to use the qtest_clock. What's nice about that is that you can simulate long periods of time (2 years) in a short period of time and do long term drift testing. I know the math in the rtc is broken right now because we assume that there's a rational conversion from RTC cycle frequency to nanoseconds which is not the case. We need a more sophisticated approach that can maintain an irrational conversion factor (in the form of a fractional multiplier). Regards, Anthony Liguori > and busy loop running that method using UIP like you would do > on hardware. > > Paolo > >