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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
