On Thu, Jan 25, 2018 at 3:36 AM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 23 January 2018 at 22:24, Alistair Francis
> <alistair.fran...@xilinx.com> wrote:
>> Allow the guest to determine the time set from the QEMU command line.
>>
>> This includes adding a trace event to debug the new time.
>>
>> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>> ---
>> static const VMStateDescription vmstate_rtc = {
>> .name = TYPE_XLNX_ZYNQMP_RTC,
>> .version_id = 1,
>> .minimum_version_id = 1,
>> + .post_load = rtc_post_load,
>> .fields = (VMStateField[]) {
>> VMSTATE_UINT32_ARRAY(regs, XlnxZynqMPRTC, XLNX_ZYNQMP_RTC_R_MAX),
>> + VMSTATE_INT32(current_tm.tm_sec, XlnxZynqMPRTC),
>> + VMSTATE_INT32(current_tm.tm_min, XlnxZynqMPRTC),
>> + VMSTATE_INT32(current_tm.tm_hour, XlnxZynqMPRTC),
>> + VMSTATE_INT32(current_tm.tm_wday, XlnxZynqMPRTC),
>> + VMSTATE_INT32(current_tm.tm_mday, XlnxZynqMPRTC),
>> + VMSTATE_INT32(current_tm.tm_mon, XlnxZynqMPRTC),
>> + VMSTATE_INT32(current_tm.tm_year, XlnxZynqMPRTC),
>
> I'm still not sure about having the current_tm struct fields
> here rather than whatever the hardware's natural representation
> of the current time is. Can you explain why you think this
> is the best approach?
This means that the only thing we have to track is the time that the
user set, either through the QEMU command line arguments as an
override or the original starting time. Then from there we can always
calculate the correct offset based on our current time.
I don't see a nicer way, otherwise we need to recalculate the natural
representation before and after migration using something more
complex. This way it's always the same logic, we just run it at init
and after migration.
Alistair
>
> thanks
> -- PMM
