Re: [Qemu-devel] pl031 time across vm save/reload

[Paolo Bonzini]

On 04/07/19 18:02, Peter Maydell wrote:
> I've had a report that the way the PL031 model handles time
> across a vm save/reload fails to correctly advance the guest
> RTC when the host RTC has advanced between the save and reload.
> I looked at the code and my correspondent's analysis (which
> I quote below, lightly edited) looks correct to me, but I'm not
> entirely sure how our RTC stuff is supposed to work. Paolo,
> you wrote this (way back in commit b0f26631bc5179006) -- any opinions?
> 
> In the pl031 RTC device. the current time is given by:
> 
>     int64_t now = qemu_clock_get_ns(rtc_clock);
>     return s->tick_offset + now / NANOSECONDS_PER_SECOND;
> 
> On save we do:
> 
>     /* tick_offset is base_time - rtc_clock base time.  Instead, we want to
>      * store the base time relative to the QEMU_CLOCK_VIRTUAL for
> backwards-compatibility.  */
>     int64_t delta = qemu_clock_get_ns(rtc_clock) -
> qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
>     s->tick_offset_vmstate = s->tick_offset + delta / NANOSECONDS_PER_SECOND;
> 
> On restore:
> 
>     int64_t delta = qemu_clock_get_ns(rtc_clock) -
> qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
>     s->tick_offset = s->tick_offset_vmstate - delta / NANOSECONDS_PER_SECOND;
> 
> So, no matter what is requested, if "qemu_clock_get_ns(rtc_clock)"
> increases (eg, because host time increased), then tick_offset
> reduces, which makes time follow QEMU_CLOCK_VIRTUAL no matter what
> was requested on qemu's command line.
> 
> (That is, because we migrate "offset relative to CLOCK_VIRTUAL"
> and CLOCK_VIRTUAL does not advance when the VM is stopped,
> we don't get the right behaviour of "offset is relative to
> the new CLOCK_RTC, which might have advanced".).

You're right, the compatibility causes wrong behavior for the default
-rtc settings (the RC pauses across migration).  The right thing to do
would be to store the base rather than the offset: that is, you store
the time at which LR was written.  Then the offset is s->lr - s->base
and it's independent of the machine on which the rtc_clock is being read.

By the way, the data sheet says "the counter and match values are
compared in a comparator. When both values are equal, the RTCINTR
interrupt is asserted HIGH"; QEMU compares the RTC value (read from
RTC_DR) and not the counter value, but Linux code seems to expect QEMU's
behavior.

Paolo