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. thanks -- PMM
