Skip to content

Conversation

@bchalios
Copy link
Contributor

Changes

Add basic support for VMClock device in Firecracker. VMClock is a virtual device that conveys information that help guest synchronise applications clocks against real wallclock time. The device is implemented as an ACPI device in Linux, as a result we can now support it only in x86.

For the time being we only support the disruption_marker capability of the device, which informs the guest that there has occurred some disrupting event and hence applications need to re-synchronize their clocks. We don't provide any underlying clock information which helps with calibration.

Reason

We want to start using the device to help guests know when they need to re-calibrate clocks. In the future we might also pass in information that helps with clock synchronization.

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

  • I have read and understand CONTRIBUTING.md.
  • I have run tools/devtool checkbuild --all to verify that the PR passes
    build checks on all supported architectures.
  • I have run tools/devtool checkstyle to verify that the PR passes the
    automated style checks.
  • I have described what is done in these changes, why they are needed, and
    how they are solving the problem in a clear and encompassing way.
  • I have updated any relevant documentation (both in code and in the docs)
    in the PR.
  • I have mentioned all user-facing changes in CHANGELOG.md.
  • If a specific issue led to this PR, this PR closes the issue.
  • When making API changes, I have followed the
    Runbook for Firecracker API changes.
  • I have tested all new and changed functionalities in unit tests and/or
    integration tests.
  • I have linked an issue to every new TODO.

  • This functionality cannot be added in rust-vmm.

@bchalios bchalios marked this pull request as draft November 11, 2025 13:45
@codecov
Copy link

codecov bot commented Nov 11, 2025

Codecov Report

❌ Patch coverage is 95.93023% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.87%. Comparing base (ceeca6a) to head (062efe2).

Files with missing lines Patch % Lines
src/vmm/src/devices/acpi/vmgenid.rs 90.90% 3 Missing ⚠️
src/vmm/src/devices/acpi/vmclock.rs 97.18% 2 Missing ⚠️
src/vmm/src/arch/aarch64/fdt.rs 88.88% 1 Missing ⚠️
src/vmm/src/device_manager/acpi.rs 97.14% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #5510      +/-   ##
==========================================
+ Coverage   82.83%   82.87%   +0.03%     
==========================================
  Files         269      270       +1     
  Lines       27723    27790      +67     
==========================================
+ Hits        22965    23030      +65     
- Misses       4758     4760       +2     
Flag Coverage Δ
5.10-m5n.metal 83.05% <96.31%> (+0.03%) ⬆️
5.10-m6a.metal 82.32% <96.31%> (+0.04%) ⬆️
5.10-m6g.metal 79.63% <71.68%> (-0.02%) ⬇️
5.10-m6i.metal 83.05% <96.31%> (+0.04%) ⬆️
5.10-m7a.metal-48xl 82.31% <96.31%> (+0.04%) ⬆️
5.10-m7g.metal 79.63% <71.68%> (-0.03%) ⬇️
5.10-m7i.metal-24xl 83.01% <96.31%> (+0.03%) ⬆️
5.10-m7i.metal-48xl 83.03% <96.31%> (+0.05%) ⬆️
5.10-m8g.metal-24xl 79.63% <71.68%> (-0.02%) ⬇️
5.10-m8g.metal-48xl 79.63% <71.68%> (-0.03%) ⬇️
6.1-m5n.metal 83.07% <96.31%> (+0.03%) ⬆️
6.1-m6a.metal 82.35% <96.31%> (+0.04%) ⬆️
6.1-m6g.metal 79.63% <71.68%> (-0.03%) ⬇️
6.1-m6i.metal 83.07% <96.31%> (+0.03%) ⬆️
6.1-m7a.metal-48xl 82.34% <96.31%> (+0.04%) ⬆️
6.1-m7g.metal 79.62% <71.68%> (-0.04%) ⬇️
6.1-m7i.metal-24xl 83.08% <96.31%> (+0.03%) ⬆️
6.1-m7i.metal-48xl 83.08% <96.31%> (+0.03%) ⬆️
6.1-m8g.metal-24xl 79.63% <71.68%> (-0.03%) ⬇️
6.1-m8g.metal-48xl 79.62% <71.68%> (-0.03%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@bchalios bchalios force-pushed the vmclock branch 5 times, most recently from 1f319ea to a62ac4c Compare November 11, 2025 18:06
@bchalios bchalios marked this pull request as ready for review November 11, 2025 18:53
@bchalios bchalios enabled auto-merge (rebase) November 11, 2025 18:53
@bchalios bchalios self-assigned this Nov 11, 2025
@bchalios bchalios added the Status: Awaiting review Indicates that a pull request is ready to be reviewed label Nov 11, 2025
@bchalios
Copy link
Contributor Author

FYI: dropped the commit that enabled VMClock in our guest kernels. Apparently the config is already present in the AL kernels

vmclock is added in Linux 6.13. Upgrade the version we are using to
create Rust bindings from to this version so we can get vmclock ABI
definitions.

Signed-off-by: Babis Chalios <bchalios@amazon.es>
Decouple creation of VMGenID device with writing the generation ID in
guest memory. This way we can avoid keeping an `Option<VmGenId>` inside
the ACPI device manager. We can always create it and only write the
generation ID in guest memory once we are ready to activate the device
(when we have a functioning guest memory object).

Also, remove a few of the error types and fail in-place instead of
propagating errors all the way up.

On the Aarch64, we need to recreate the expected dtb files because
default microVMs always create entries for the VMGenID device.

Signed-off-by: Babis Chalios <bchalios@amazon.es>
Add bindings for vmclock ABI from Linux 6.13, also add the logic in
tools/bindgen.sh to automate the process.

Signed-off-by: Babis Chalios <bchalios@amazon.es>
Implement the VMClock device on x86_64 platforms. At the moment, we just
allocate the memory region in the guest address space for exposing the
device. We don't expose any clock from the host and since we don't
support live migration, the device won't do anything at the moment, but
we should still be able to see a `/dev/vmclock` inside the guest.

We do support the `disruption_marker` field which notifies the guest to
adjust clocks due to a time shifting event.

Signed-off-by: Babis Chalios <bchalios@amazon.es>
Add tests that validate that VMClock device as exposed inside the guest
under /dev/vmclock0 works as expected. This includes a small C program
that knows how to open and read values from /dev/vmclock0.

Signed-off-by: Babis Chalios <bchalios@amazon.es>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Status: Awaiting review Indicates that a pull request is ready to be reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant