|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH 15/15] qtest: add rtc-test test-case |
Date: | Wed, 11 Jan 2012 11:06:46 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |