fix(kvm-clock): do not jump monotonic clock on restore#5809
Open
Manciukic wants to merge 3 commits intofirecracker-microvm:mainfrom
Open
fix(kvm-clock): do not jump monotonic clock on restore#5809Manciukic wants to merge 3 commits intofirecracker-microvm:mainfrom
Manciukic wants to merge 3 commits intofirecracker-microvm:mainfrom
Conversation
Manciukic
force-pushed
the
fix-clock-jump
branch
from
440e557 to
0e18583
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5809 +/- ##
==========================================
- Coverage 83.00% 82.99% -0.01%
==========================================
Files 275 275
Lines 29383 29399 +16
==========================================
+ Hits 24388 24401 +13
- Misses 4995 4998 +3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Manciukic
force-pushed
the
fix-clock-jump
branch
4 times, most recently
from
295403e to
9565fa8
Compare
Manciukic
added
the
Status: Awaiting review
kalyazin
reviewed
Apr 2, 2026
Manciukic
force-pushed
the
fix-clock-jump
branch
from
9565fa8 to
4ecfc15
Compare
ilstam
reviewed
Apr 2, 2026
ilstam
reviewed
Apr 2, 2026
| When using `kvm-clock` as clock source on `x86_64`, it's possible to optionally | ||
| set the `clock_realtime: true` in the `LoadSnapshot` request to advance the | ||
| clock source on the guest at restore time. Note that this may cause issues | ||
| within the guest as the clock source will appear to suddenly jump. |
Contributor
Author
There was a problem hiding this comment.
the second one at line 498? yeah that makes sense
Manciukic
force-pushed
the
fix-clock-jump
branch
from
4ecfc15 to
0ea8a12
Compare
ilstam
reviewed
Apr 2, 2026
ilstam
reviewed
Apr 2, 2026
CHANGELOG.md
Outdated
| - [#5809](https://github.com/firecracker-microvm/firecracker/pull/5809): Fixed a | ||
| bug on host Linux >= 5.16 for x86_64 guests using the `kvm-clock` clock source | ||
| causing the monotonic clock to jump on restore by the wall-clock time elapsed | ||
| since the snapshot was taken. Users that want to keep the previous behaviour |
Contributor
There was a problem hiding this comment.
I think 'previous' is ambiguous in this paragraph. I think it should be explicit what is the behaviour as of the new version and what does setting clock_realtime does.
Contributor
Author
There was a problem hiding this comment.
I can mention the KVM_CLOCK_REALTIME instead of just "previous behaviour".
Contributor
Author
There was a problem hiding this comment.
Users using
kvm-clockthat want to explicitly advance the clock withKVM_CLOCK_REALTIMEcan opt back in...
Removes trailing whitespace. Signed-off-by: Riccardo Mancini <mancio@amazon.com>
ilstam
previously approved these changes
Apr 2, 2026
Firecracker has never advanced the clock on restore for any of the supported clocksources. Since Linux 5.16, the KVM_CLOCK_REALTIME has been passed to kvm-clock, causing the monotonic time in the guest to jump when using kvm-clock as clock source. Despite being unexpected and not what Firecracker should do, we recognize this may be a valid usecase so this patch adds a way to configure it, keeping the default to the expected documented behaviour. This patch adds a new API flag to LoadSnapshot, clock_realtime, that advances the clock on restore when set (default is False). Rather than the clock flags being decided at snapshot time, the restore path ignores those flags and decides what to do depending on the clock_realtime flag. This is because the other available flag (KVM_CLOCK_TSC_STABLE) cannot even be passed to `set_clock`, meaning the only valid flag is KVM_CLOCK_REALTIME. The name of the flag was kept generic as we may add this behaviour for the other clock sources in the future, if the need arises. Signed-off-by: Riccardo Mancini <mancio@amazon.com>
We actually support all of them. Signed-off-by: Riccardo Mancini <mancio@amazon.com>
Manciukic
force-pushed
the
fix-clock-jump
branch
from
0ea8a12 to
c7c682c
Compare
kalyazin
approved these changes
Apr 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes
This patch adds a new API flag to LoadSnapshot, clock_realtime, that advances the clock on restore when set (default is False). Rather than the clock flags being decided at snapshot time, the restore path ignores those flags and decides what to do depending on the clock_realtime flag. This is because the other available flags are ignored (KVM_CLOCK_TSC_HOST) or cannot be passed to
set_clock(KVM_CLOCK_TSC_STABLE) , meaning the only valid flag is KVM_CLOCK_REALTIME.The name of the flag was kept generic as we may add this behaviour for the other clock sources in the future, if the need arises.
Reason
Firecracker has never advanced the clock on restore for any of the supported clocksources. Since Linux 5.16, the KVM_CLOCK_REALTIME has been passed to kvm-clock, causing the monotonic time in the guest to jump when using kvm-clock as clock source.
Despite being unexpected and not what Firecracker should do, we recognize this may be a valid usecase so this patch adds a way to configure it, keeping the default to the expected documented behaviour.
License Acceptance
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.PR Checklist
tools/devtool checkbuild --allto verify that the PR passesbuild checks on all supported architectures.
tools/devtool checkstyleto verify that the PR passes theautomated style checks.
how they are solving the problem in a clear and encompassing way.
in the PR.
CHANGELOG.md.Runbook for Firecracker API changes.
integration tests.
TODO.rust-vmm.