mc146818rtc: implement UIP latching as intended
commit33f21e4f044ac1c37f60edc1f1aee628be8f463b
authorPaolo Bonzini <pbonzini@redhat.com>
Tue, 25 Jul 2017 12:55:38 +0000 (25 14:55 +0200)
committerPaolo Bonzini <pbonzini@redhat.com>
Tue, 1 Aug 2017 15:27:34 +0000 (1 17:27 +0200)
tree07f1883e6716d5064c9d97be69c74b401fb9f15e
parent6a51d83a17e8213db353dd6756685fd9e3513e13
mc146818rtc: implement UIP latching as intended

In some cases, the guest can observe the wrong ordering of UIP and
interrupts.  This can happen if the VCPU exit is timed like this:

           iothread                 VCPU
                                  ... wait for interrupt ...
t-100ns                           read register A
t          wake up, take BQL
t+100ns                             update_in_progress
                                      return false
                                    return UIP=0
           trigger interrupt

The interrupt is late; the VCPU expected the falling edge of UIP to
happen after the interrupt.  update_in_progress is already trying to
cover this case by latching UIP if the timer is going to fire soon,
and the fix is documented in the commit message for commit 56038ef623
("RTC: Update the RTC clock only when reading it", 2012-09-10).  It
cannot be tested with qtest, because its timing of interrupts vs. reads
is exact.

However, the implementation was incorrect because UIP cmos_ioport_read
cleared register A instead of leaving that to rtc_update_timer.  Fixing
the implementation of cmos_ioport_read to match the commit message,
however, breaks the "uip-stuck" test case from the previous patch.
To fix it, skip update timer optimizations if UIP has been latched.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
hw/timer/mc146818rtc.c