Hi Eric,
Have you ever tested the value reported by the PL031 RTC_CHANGE when
the qemu clock is using the virtual clock, which is not identical to
mc146818.
For instance, adding 20s to the guest RTC value, the expected value should be
20, but the actual value is 1652863291:
{"timestamp": {"seconds": 1652863355, "microseconds": 298846}, "event":
"RTC_CHANGE", "data": {"offset":
1652863291}}
This is tested with qemu option "-rtc base=utc,clock=vm"
> s->tick_offset += value - pl031_get_count(s);
>+
>+ qemu_get_timedate(&tm, s->tick_offset);
>+ qapi_event_send_rtc_change(qemu_timedate_diff(&tm));
It may be caused by the calculation of the new reference time. The new reference
time is calculated with s->tick_offset and rtc_ref_start_datetime, and
s->tick_offset is initialized with rtc_ref_start_datetime, resulting that the
rtc_ref_start_datetime is double counting.
Thanks
