virtio-devices: Implement a backend for virtio-rtc by Camelron · Pull Request #7795 · cloud-hypervisor/cloud-hypervisor

Camelron · 2026-03-06T00:26:44Z

Motivation

This change will allow us to get accurate time over ptp in guests started from
a MSHV-virtualized Linux host. Implementing it as a virtio device is preferable
to using the existing kvm_ptp because:

kvm_ptp relies on hypercalls that only exist on host kernels running kvm.
virtio-rtc gives us more flexibility in what clock types we want to provide.
We can later extend the device to implement multiple clocks
(smeared UTC, TAI, monotonic, etc.). Virtio-rtc protocol supports alarms.
Alarms may later enable usecases where the guests can do their own VM lifecycle
management without relying on a host-side orchestrator.

Change

Implement device backend for virtio-rtc. Currently this implementation
encompasses:

CONFIG, CAP, READ, CROSSCAP (returns false)
One PTP clock is presented of type VIRTIO_RTC_CLOCK_UTC_SMEARED

KVM guests can already use kvm_ptp which is synchronous
and therefore, more accurate.

Not implemented but theoretically supported by virtio-rtc is:

Cross-timestamping support
The alarm queue

Fixes #7730

Camelron · 2026-03-06T01:29:09Z

Since it is probably relevant, I tested the case where we have a kvm-based guest with a kernel with both VIRTIO_PTP and CONFIG_PTP_1588_CLOCK_KVM.

Here we see that they are both available.

root [ / ]# cat /sys/class/ptp/ptp
ptp0/ ptp1/ 
root [ / ]# cat /sys/class/ptp/ptp0/clock_name 
Virtio PTP type 3/variant 0
root [ / ]# cat /sys/class/ptp/ptp1/clock_name 
KVM virtual PTP

The consequence of this is that guest images may need udev rules to distinguish between them e.g.

# /etc/udev/rules.d/99-ptp.rules
SUBSYSTEM=="ptp", ATTR{clock_name}=="Virtio PTP type 3/variant 0", SYMLINK+="ptp_virtio"
SUBSYSTEM=="ptp", ATTR{clock_name}=="KVM virtual PTP", SYMLINK+="ptp_kvm"

DemiMarie · 2026-03-06T07:39:54Z

Does MSHV already have a paravirtualized timekeeping device?

Camelron · 2026-03-06T20:39:15Z

Does MSHV already have a paravirtualized timekeeping device?

We do--hyperv_clocksource_tsc_page. However hyperv_clocksource_tsc_page is a host-controlled clock, not a guest PHC device which is steerable in the guest by something like chronyd.

phip1611 · 2026-03-09T10:34:49Z

Your PR and commit messages are missing a # Motivation section. A single descriptive sentence would be enough (who/which component would use that and why is it better than the status quo?). Could you please add one?

liuw · 2026-03-23T17:15:35Z

@Camelron there seems to be some recent changes in the main branch. You need to rebase to the latest and build it locally before pushing again.

See commit f77c6ef.

phip1611 · 2026-03-27T14:16:51Z

ping @Camelron please fix your commit message and the CI

Camelron · 2026-03-27T22:48:19Z

Looking at the Tests (arm64) failure, it appears to be failing to build the devices crate due to a missing cached dependency? Hopefully transient?

Looking at the x86 failures, I see now that the tests depend on the ordering of PCI devices added to the guest. Pushing a fix to make virtio_rtc the last PCI device added (bdf 09..) since it was added most recently. Also incrementing the expected /sys/bus/pci/devices count to 9.

The virtio_rtc test appears to be failing despite recently merging the change to enable the virtio-rtc driver in the guest kernel: cloud-hypervisor/linux#26 . @weltling @phip1611 is there a way to verify in the CI what kernel version we use for the guest? I see that we are using 6.16.9+ which is the branch I merged the config change into..

weltling · 2026-03-30T16:00:09Z

kernel: cloud-hypervisor/linux#26 . @weltling @phip1611 is there a way to verify in the CI what kernel version we use for the guest? I see that we are using 6.16.9+ which is the branch I merged the config change into..

As far as it shows, there's no new kernel release yet, so guess it's not updated on CI yet.

For the other tests - those seem irrelevant. Though, you could just retrigger the PR or check as a PR against your own fork, if it tells the diff. But most likely not necessary.

Thanks

Camelron · 2026-03-31T20:12:43Z

I see all tests passing except the new virtio_rtc one https://productionresultssa9.blob.core.windows.net/actions-results/523784af-3a03-45ad-9c14-2ed707123c35/workflow-job-run-6c0528a0-29fa-5100-b69e-2e46da316d43/logs/job/job-logs.txt?rsct=text%2Fplain&se=2026-03-31T20%3A17%3A46Z&sig=wZ7EGKxhVgJAdQ5g6v3s9PDmF%2FSnj%2BfwA451bTFKAbc%3D&ske=2026-03-31T22%3A36%3A50Z&skoid=ca7593d4-ee42-46cd-af88-8b886a2f84eb&sks=b&skt=2026-03-31T18%3A36%3A50Z&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skv=2025-11-05&sp=r&spr=https&sr=b&st=2026-03-31T20%3A07%3A41Z&sv=2025-11-05. We are now waiting for a release 03/24 or later here https://github.com/cloud-hypervisor/linux/releases to verify that the new test passes once the driver is available in the guest.

Thanks!

phip1611 · 2026-04-01T05:12:13Z

We are now waiting for a release 03/24 or later here cloud-hypervisor/linux/releases to verify that the new test passes once the driver is available in the guest.

Is someone actively working on that? What are the next steps to proceed here? Sorry, I don't have the full context of this right now

liuw · 2026-04-02T18:29:52Z

There is a pending release for the kernel by github-actions. @rbradford @likebreath can we publish that?

likebreath · 2026-04-02T21:15:25Z

There is a pending release for the kernel by github-actions. @rbradford @likebreath can we publish that?

Done! Here it is: https://github.com/cloud-hypervisor/linux/releases/tag/ch-release-v6.16.9-20260324

Camelron · 2026-04-09T16:25:23Z

@rbradford all changes in the CI are now accounted for and we are passing. Mind taking a final look?

Thank you.

rbradford

I don't think this should always be included as PCI slots are valuable resource on segment 0, especially on KVM where there is already kvmclock and this doesn't add any functionality.

Please make it conditional like watchdog - I would be happy for it to be a different default depending on the running hypervisor.

rbradford · 2026-04-12T09:25:19Z

    assert!(
        exec_host_command_status(&format!(
-            "sudo ip link add link {phy_net} name {host_macvtap_name} type macvtap mod bridge"
+            "sudo ip link add link {phy_net} name {host_macvtap_name} type macvtap mode bridge"


I'm assuming this worked before but it just nicer aesthetically? It's a good change but it deserves its own commit.

I did hit a failure due to this "mod bridge" hence the change. I don't see how though with the CI already persisting long before I came around. Will pull it out for now and see if things pass as-is.

rbradford · 2026-04-12T09:37:57Z

            VirtioDeviceType::Vsock => "vsock",
            VirtioDeviceType::Iommu => "iommu",
            VirtioDeviceType::Mem => "mem",
+            VirtioDeviceType::Rtc => "rtc",


I feel like this should be in the same order as the numerical order (i.e. same order as From<..> implementation,

phip1611 · 2026-04-13T07:26:22Z

I don't think this should always be included as PCI slots are valuable resource on segment 0, especially on KVM where there is already kvmclock and this doesn't add any functionality.

Yup, please no more implicit default devices. This makes BDF handling in management software (e.g., libvirt) more complicated.

rbradford · 2026-04-16T17:10:45Z

@Camelron Ping?

Camelron · 2026-04-17T17:42:14Z

Sorry, I've been heads down on some other tasks. Will address requested changes today.

Camelron · 2026-04-17T18:15:05Z

            VirtioDeviceType::Rng => "rng",
            VirtioDeviceType::Balloon => "balloon",
-            VirtioDeviceType::Gpu => "gpu",
            VirtioDeviceType::Fs9P => "9p",


9p was in the wrong order too so I moved it. Can be separated out if preferred.

Move to the latest release for cloud-hypervisor/linux. Contains configs needed for virtio-rtc Signed-off-by: Cameron Baird <cameronbaird@microsoft.com>

This change will allow us to get accurate time over ptp in guests started from a MSHV-virtualized Linux host. Implementing it as a virtio device is preferable to using the existing kvm_ptp because: kvm_ptp relies on hypercalls that only exist on host kernels running kvm. Virtio-rtc gives us more flexibility in what clock types we want to provide. We can later extend the device to implement multiple clocks (smeared UTC, TAI, monotonic, etc.). Virtio-rtc protocol supports alarms. Alarms may later enable usecases where the guests can do their own VM lifecycle management without relying on a host-side orchestrator. Implement device backend for virtio-rtc. Currently this implementation encompasses: 1. CONFIG, CAP, READ, CROSSCAP (returns false) 2. One PTP clock is presented of type VIRTIO_RTC_CLOCK_UTC_SMEARED The device is disable by default, requiring --virtio-rtc to be passed Not implemented but theoretically supported by virtio-rtc is: 1. Cross-timestamping support 2. The alarm queue Fixes cloud-hypervisor#7730 Signed-off-by: Cameron Baird <cameronbaird@microsoft.com>

Integration test for virtio-devices/src/rtc.rs. Requires that the test kernel has the following configs: CONFIG_PTP_1588_CLOCK=y CONFIG_VIRTIO_RTC=y CONFIG_VIRTIO_RTC_PTP=y Signed-off-by: Cameron Baird <cameronbaird@microsoft.com>

Camelron · 2026-04-17T21:36:46Z

@rbradford all comments should now be addressed.

Camelron requested a review from a team as a code owner March 6, 2026 00:26

Camelron commented Mar 6, 2026

View reviewed changes

Comment thread cloud-hypervisor/tests/integration.rs Outdated

rbradford requested changes Mar 6, 2026

View reviewed changes

Comment thread vmm/src/device_manager.rs Outdated

Comment thread vmm/src/device_manager.rs Outdated

liuw reviewed Mar 6, 2026

View reviewed changes

Comment thread vmm/src/device_manager.rs Outdated

Comment thread virtio-devices/src/rtc.rs Outdated

Camelron force-pushed the cameronbaird/virtio-rtc branch from 20490ff to 8071262 Compare March 6, 2026 01:08

weltling reviewed Mar 6, 2026

View reviewed changes

Comment thread virtio-devices/src/rtc.rs Outdated

weltling reviewed Mar 6, 2026

View reviewed changes

Comment thread virtio-devices/src/rtc.rs Outdated

weltling reviewed Mar 6, 2026

View reviewed changes

Comment thread virtio-devices/src/rtc.rs

weltling reviewed Mar 6, 2026

View reviewed changes

Comment thread virtio-devices/src/rtc.rs Outdated

weltling reviewed Mar 6, 2026

View reviewed changes

Comment thread cloud-hypervisor/tests/integration.rs

Camelron force-pushed the cameronbaird/virtio-rtc branch from 8071262 to d9e65fd Compare March 6, 2026 20:25

weltling reviewed Mar 7, 2026

View reviewed changes

Comment thread cloud-hypervisor/tests/integration.rs Outdated

weltling reviewed Mar 7, 2026

View reviewed changes

Comment thread virtio-devices/src/rtc.rs

weltling reviewed Mar 7, 2026

View reviewed changes

Comment thread virtio-devices/src/rtc.rs

weltling reviewed Mar 7, 2026

View reviewed changes

Comment thread virtio-devices/src/rtc.rs

weltling reviewed Mar 7, 2026

View reviewed changes

Comment thread virtio-devices/src/rtc.rs

Camelron force-pushed the cameronbaird/virtio-rtc branch 2 times, most recently from d6f64e8 to 76738c2 Compare March 10, 2026 20:25

weltling reviewed Mar 11, 2026

View reviewed changes

Comment thread cloud-hypervisor/tests/integration.rs Outdated

weltling reviewed Mar 11, 2026

View reviewed changes

Comment thread virtio-devices/src/rtc.rs

Camelron force-pushed the cameronbaird/virtio-rtc branch 2 times, most recently from 2ed954a to 12f98a9 Compare March 11, 2026 20:48

liuw reviewed Mar 14, 2026

View reviewed changes

Comment thread cloud-hypervisor/tests/integration.rs

Camelron force-pushed the cameronbaird/virtio-rtc branch from 12f98a9 to ac105ed Compare March 23, 2026 16:33

liuw approved these changes Mar 23, 2026

View reviewed changes

rbradford marked this pull request as draft March 27, 2026 15:06

Camelron force-pushed the cameronbaird/virtio-rtc branch from e63a78b to ee0be56 Compare March 27, 2026 22:47

Camelron marked this pull request as ready for review March 27, 2026 22:48

Camelron force-pushed the cameronbaird/virtio-rtc branch from 5ccd181 to cdb3bc2 Compare March 31, 2026 20:11

Camelron force-pushed the cameronbaird/virtio-rtc branch from a7583a6 to 2853baa Compare April 3, 2026 18:09

liuw force-pushed the cameronbaird/virtio-rtc branch from 2853baa to f24f8c0 Compare April 4, 2026 05:15

Camelron force-pushed the cameronbaird/virtio-rtc branch 2 times, most recently from 83f2c6d to 244e9d8 Compare April 8, 2026 17:27

rbradford requested changes Apr 12, 2026

View reviewed changes

Camelron force-pushed the cameronbaird/virtio-rtc branch 3 times, most recently from f711a6f to 6b4ad2d Compare April 17, 2026 18:08

Camelron commented Apr 17, 2026

View reviewed changes

ci: Move to KERNEL_TAG ch-release-v6.16.9-20260324

81b9a90

Move to the latest release for cloud-hypervisor/linux. Contains configs needed for virtio-rtc Signed-off-by: Cameron Baird <cameronbaird@microsoft.com>

Camelron force-pushed the cameronbaird/virtio-rtc branch from 6b4ad2d to 9cb7ded Compare April 17, 2026 18:45

Camelron added 2 commits April 17, 2026 19:10

ci: Add integration test for virtio-rtc

b7f20c1

Integration test for virtio-devices/src/rtc.rs. Requires that the test kernel has the following configs: CONFIG_PTP_1588_CLOCK=y CONFIG_VIRTIO_RTC=y CONFIG_VIRTIO_RTC_PTP=y Signed-off-by: Cameron Baird <cameronbaird@microsoft.com>

Camelron force-pushed the cameronbaird/virtio-rtc branch from 9cb7ded to b7f20c1 Compare April 17, 2026 19:11

Conversation

Camelron commented Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Change

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Camelron commented Mar 6, 2026

Uh oh!

DemiMarie commented Mar 6, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Camelron commented Mar 6, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

phip1611 commented Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

liuw commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

phip1611 commented Mar 27, 2026

Uh oh!

Camelron commented Mar 27, 2026

Uh oh!

weltling commented Mar 30, 2026

Uh oh!

Camelron commented Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

phip1611 commented Apr 1, 2026

Uh oh!

liuw commented Apr 2, 2026

Uh oh!

likebreath commented Apr 2, 2026

Uh oh!

Camelron commented Apr 9, 2026

Uh oh!

rbradford left a comment

Choose a reason for hiding this comment

Uh oh!

rbradford Apr 12, 2026

Choose a reason for hiding this comment

Uh oh!

Camelron Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

rbradford Apr 12, 2026

Choose a reason for hiding this comment

Uh oh!

phip1611 commented Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rbradford commented Apr 16, 2026

Uh oh!

Camelron commented Apr 17, 2026

Uh oh!

Camelron Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

Camelron commented Apr 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Camelron commented Mar 6, 2026 •

edited

Loading

phip1611 commented Mar 9, 2026 •

edited

Loading

liuw commented Mar 23, 2026 •

edited

Loading

Camelron commented Mar 31, 2026 •

edited

Loading

phip1611 commented Apr 13, 2026 •

edited

Loading