On 8 February 2018 at 17:21, Alistair Francis
wrote:
> On Thu, Feb 8, 2018 at 7:42 AM, Peter Maydell
> wrote:
>> 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 re
On Thu, Feb 8, 2018 at 7:42 AM, Peter Maydell wrote:
> On 26 January 2018 at 01:09, Alistair Francis
> wrote:
>> On Thu, Jan 25, 2018 at 3:36 AM, Peter Maydell
>> wrote:
>>> I'm still not sure about having the current_tm struct fields
>>> here rather than whatever the hardware's natural represe
On 26 January 2018 at 01:09, Alistair Francis
wrote:
> On Thu, Jan 25, 2018 at 3:36 AM, Peter Maydell
> 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 thi
On Thu, Jan 25, 2018 at 3:36 AM, Peter Maydell wrote:
> On 23 January 2018 at 22:24, Alistair Francis
> 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
>> ---
>>
On 23 January 2018 at 22:24, Alistair Francis
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
> ---
> static const VMStateDescription vmstate_rtc = {
> .name = TY
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
---
V5:
- Recalculate tick_offset after migration
V4:
- Use the .unimp property
V3:
- Store an offset value
- Use mktimegm()
- Log
