qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Question about commit 1adf528ec3bd ("hw/rtc/pl031: Send RTC_CHANGE QMP e


From: jokenzhang
Subject: Question about commit 1adf528ec3bd ("hw/rtc/pl031: Send RTC_CHANGE QMP event")
Date: Wed, 18 May 2022 17:55:46 +0800
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.3

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]