Re: Question about commit 1adf528ec3bd ("hw/rtc/pl031: Send RTC_CHANGE QMP event")

[Eric Auger <eric.auger@redhat.com>]

Hi,

On 5/18/22 11:55, jokenzhang via wrote:
> 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"

I did not test with clock=vm unfortunately. Those was my test setup:

"Tested with the following script run on guest:

  #!/bin/sh
  old=$(hwclock --show | cut -f1-7 -d' ')
  oldabs=$(date +%s -d "$old")
  newabs=$(expr $oldabs + $1)
  new=$(date -d @"$newabs")
  echo Old: $oldabs $old
  echo New: $newabs $new
  hwclock --set --date "$new"

This was tested with both -rtc base=2010-12-03T01:02:00 and base=utc
qemu options. As far as I can see the reported value match what
is observed on x86 (except on x86 the values are not exactly the one
used on guest, ie. 18 for instance instead of 20).
"

>
>>         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.
I must aknowledge I am not really familiar with the clock framwork. If
you studied that code already, please feel free to send a patch, I will
help testing.

Thanks


Eric

>
>
> Thanks
>