[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v5 2/3] xlnx-zynqmp-rtc: Add basic time support

From: Alistair Francis
Subject: Re: [Qemu-devel] [PATCH v5 2/3] xlnx-zynqmp-rtc: Add basic time support
Date: Thu, 8 Feb 2018 09:21:01 -0800

On Thu, Feb 8, 2018 at 7:42 AM, Peter Maydell <address@hidden> wrote:
> On 26 January 2018 at 01:09, Alistair Francis
> <address@hidden> wrote:
>> On Thu, Jan 25, 2018 at 3:36 AM, Peter Maydell <address@hidden> wrote:
>>> 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.
> Doing it this way round means that it gets complicated when the
> guest writes to the RTC, though. At the moment I can't see anywhere
> that sets the current_tm fields except for reset and post-migration.
> Isn't something missing here? I'm wondering if this choice of
> migration state is going to paint us into a corner for handling
> guest-writes-to-rtc.

I don't have guest write support. The main focus was just allowing
users to set the time when they boot QEMU. We haven't seen any request
to allow guests to set the time, so I didn't bother.

Wouldn't adding guest write support just be as simple as converting
the value written to a current_tm field?


> thanks
> -- PMM

reply via email to

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