fix(kvm-clock): do not jump monotonic clock on restore#5809
Merged
Manciukic merged 3 commits intofirecracker-microvm:mainfrom Apr 7, 2026
Merged
fix(kvm-clock): do not jump monotonic clock on restore#5809Manciukic merged 3 commits intofirecracker-microvm:mainfrom
Manciukic merged 3 commits intofirecracker-microvm:mainfrom
Conversation
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:
|
295403e to
9565fa8
Compare
kalyazin
reviewed
Apr 2, 2026
9565fa8 to
4ecfc15
Compare
ilstam
reviewed
Apr 2, 2026
ilstam
reviewed
Apr 2, 2026
4ecfc15 to
0ea8a12
Compare
ilstam
reviewed
Apr 2, 2026
ilstam
reviewed
Apr 2, 2026
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>
0ea8a12 to
c7c682c
Compare
kalyazin
approved these changes
Apr 3, 2026
ilstam
approved these changes
Apr 7, 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
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.