qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] spapr: clock should count only if vm is running


From: Laurent Vivier
Subject: Re: [Qemu-devel] [PATCH] spapr: clock should count only if vm is running
Date: Fri, 27 Jan 2017 11:52:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0

On 27/01/2017 10:45, Thomas Huth wrote:
> On 26.01.2017 21:45, Laurent Vivier wrote:
>> This is a port to ppc of the i386 commit:
>>     00f4d64 kvmclock: clock should count only if vm is running
>>
>> We remove timebase_/pre_save/post_load/ functions,
>> and use the VM state change handler to save and restore
>> the guest_timebase (on stop and continue).
>>
>> Time base offset has originally been introduced by commit
>>     98a8b52 spapr: Add support for time base offset migration
>>
>> So while VM is paused, the time is stopped. This allows to have
>> the same result with date (based on Time Base Register) and
>> hwclock (based on "get-time-of-day" RTAS call).
>>
>> Moreover in TCG mode, the Time Base is always paused, so this
>> patch also adjust the behavior between TCG and KVM.
>>
>> VM state field "time_of_the_day_ns" is now useless but we keep
>> it to be able to migrate to older version of the machine.
> 
> Not sure, but the cpu_ppc_clock_vm_state_change() handler is only used
> with KVM, isn't it? So what happens if you migrate in TCG mode from a
> new QEMU to an older one? Don't you have to update time_of_the_day_ns
> here somewhere, too (e.g. in a pre_save handler)?

This will be fixed because I'm preparing a new version with the pre_save
function to answer to the comment of Paolo and to do like in:
    6053a86 kvmclock: reduce kvmclock difference on migration

But originally the time_of_the_day_ns was to compensate the time
difference between two hosts (QEMU_CLOCK_HOST), and I think this is not
used in case of TCG because we use the virtual clock
(QEMU_CLOCK_VIRTUAL) that is stopped and migrated independently
(cpu_clock_offset in vmstate_timers).

Thanks,
Laurent



reply via email to

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