diff options
| author | Rodrigo Dias Correa <r@drigo.nl> | 2025-01-14 22:21:50 +0100 |
|---|---|---|
| committer | Alistair Francis <alistair.francis@wdc.com> | 2025-03-04 15:42:54 +1000 |
| commit | 3521f9cadc29c7d68b73b325ddb46a7acebf6212 (patch) | |
| tree | da329ba167feea2ee0948ffa0080aaea62d788d6 /tests/functional/qemu_test/linuxkernel.py | |
| parent | a975e733a02ba5f1e1133c97cfe1545b08fe1fbc (diff) | |
| download | qemu-3521f9cadc29c7d68b73b325ddb46a7acebf6212.zip qemu-3521f9cadc29c7d68b73b325ddb46a7acebf6212.tar.gz qemu-3521f9cadc29c7d68b73b325ddb46a7acebf6212.tar.bz2 | |
goldfish_rtc: Fix tick_offset migration
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 looks like this calculation was
copied from pl031 RTC, which had its tick_offset migration fixed by
Commit 032cfe6a79c8 ("pl031: Correctly migrate state when using -rtc
clock=host").
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
Signed-off-by: Rodrigo Dias Correa <r@drigo.nl>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250114212150.228241-1-r@drigo.nl>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Diffstat (limited to 'tests/functional/qemu_test/linuxkernel.py')
0 files changed, 0 insertions, 0 deletions