06.03.2025 09:35, Michael Tokarev wrote:
Migrate the tick_offset directly, adding it as a version-dependent field
to VMState. Keep the old behavior when migrating from previous versions.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2033
Is this a qemu-stable material?
It is proba
On Thu, Mar 6, 2025 at 4:44 PM Michael Tokarev wrote:
>
> 06.03.2025 09:35, Michael Tokarev wrote:
>
> >> Migrate the tick_offset directly, adding it as a version-dependent field
> >> to VMState. Keep the old behavior when migrating from previous versions.
> >>
> >> Resolves: https://gitlab.com/qe
15.01.2025 00:21, Rodrigo Dias Correa wrote:
Instead of migrating the raw tick_offset, goldfish_rtc migrates a
recalculated value based on QEMU_CLOCK_VIRTUAL. As QEMU_CLOCK_VIRTUAL
stands still across a save-and-restore cycle, the guest RTC becomes out
of sync with the host RTC when the VM is res
On Wed, Jan 15, 2025 at 7:23 AM Rodrigo Dias Correa wrote:
>
> Instead of migrating the raw tick_offset, goldfish_rtc migrates a
> recalculated value based on QEMU_CLOCK_VIRTUAL. As QEMU_CLOCK_VIRTUAL
> stands still across a save-and-restore cycle, the guest RTC becomes out
> of sync with the host
On Wed, Jan 15, 2025 at 7:23 AM Rodrigo Dias Correa wrote:
>
> Instead of migrating the raw tick_offset, goldfish_rtc migrates a
> recalculated value based on QEMU_CLOCK_VIRTUAL. As QEMU_CLOCK_VIRTUAL
> stands still across a save-and-restore cycle, the guest RTC becomes out
> of sync with the host
Instead of migrating the raw tick_offset, goldfish_rtc migrates a
recalculated value based on QEMU_CLOCK_VIRTUAL. As QEMU_CLOCK_VIRTUAL
stands still across a save-and-restore cycle, the guest RTC becomes out
of sync with the host RTC when the VM is restored.
As described in the bug description, it
