On Thu, Feb 8, 2018 at 7:42 AM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 26 January 2018 at 01:09, Alistair Francis > <alistair.fran...@xilinx.com> wrote: >> On Thu, Jan 25, 2018 at 3:36 AM, Peter Maydell <peter.mayd...@linaro.org> >> 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? Alistair > > thanks > -- PMM >
