Thanks to visit codestin.com
Credit goes to github.com

Skip to content

virtio-devices: Implement a backend for virtio-rtc - #7795

Merged
liuw merged 2 commits into
cloud-hypervisor:mainfrom
Camelron:cameronbaird/virtio-rtc
May 26, 2026
Merged

liuw merged 2 commits into
cloud-hypervisor:mainfrom
Camelron:cameronbaird/virtio-rtc

Conversation

@Camelron

@Camelron Camelron commented Mar 6, 2026

Copy link
Copy Markdown
Contributor

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:

  1. CONFIG, CAP, READ, CROSSCAP (returns false)
  2. One PTP clock is presented of type VIRTIO_RTC_CLOCK_UTC_MAYBE_SMEARED with leap_second_smearing VIRTIO_RTC_SMEAR_UNSPECIFIED

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

Not implemented but theoretically supported by virtio-rtc is:

  1. Cross-timestamping support
  2. The alarm queue

Fixes #7730

@Camelron
Camelron requested a review from a team as a code owner March 6, 2026 00:26
Comment thread cloud-hypervisor/tests/integration.rs Outdated
Comment thread vmm/src/device_manager.rs Outdated
Comment thread vmm/src/device_manager.rs Outdated
Comment thread vmm/src/device_manager.rs Outdated
Comment thread virtio-devices/src/rtc.rs Outdated
@Camelron
Camelron force-pushed the cameronbaird/virtio-rtc branch from 20490ff to 8071262 Compare March 6, 2026 01:08
@Camelron

Camelron commented Mar 6, 2026

Copy link
Copy Markdown
Contributor Author

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

Copy link
Copy Markdown
Contributor

Does MSHV already have a paravirtualized timekeeping device?

Comment thread virtio-devices/src/rtc.rs Outdated
Comment thread virtio-devices/src/rtc.rs Outdated
Comment thread virtio-devices/src/rtc.rs
Comment thread virtio-devices/src/rtc.rs Outdated
Comment thread cloud-hypervisor/tests/integration.rs
@Camelron
Camelron force-pushed the cameronbaird/virtio-rtc branch from 8071262 to d9e65fd Compare March 6, 2026 20:25
@Camelron

Camelron commented Mar 6, 2026

Copy link
Copy Markdown
Contributor Author

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.

Comment thread cloud-hypervisor/tests/integration.rs Outdated
Comment thread virtio-devices/src/rtc.rs
Comment thread virtio-devices/src/rtc.rs
Comment thread virtio-devices/src/rtc.rs
Comment thread virtio-devices/src/rtc.rs
@phip1611

phip1611 commented Mar 9, 2026

Copy link
Copy Markdown
Member

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?

@Camelron
Camelron force-pushed the cameronbaird/virtio-rtc branch 2 times, most recently from d6f64e8 to 76738c2 Compare March 10, 2026 20:25
Comment thread cloud-hypervisor/tests/integration.rs Outdated
Comment thread virtio-devices/src/rtc.rs
@Camelron
Camelron force-pushed the cameronbaird/virtio-rtc branch 2 times, most recently from 2ed954a to 12f98a9 Compare March 11, 2026 20:48
Comment thread cloud-hypervisor/tests/integration.rs
@Camelron
Camelron force-pushed the cameronbaird/virtio-rtc branch from 12f98a9 to ac105ed Compare March 23, 2026 16:33
@liuw

liuw commented Mar 23, 2026

Copy link
Copy Markdown
Member

@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.

@rbradford

Copy link
Copy Markdown
Member

FWIW - I did log in and delete the Image files from the workloads directory

@rbradford
rbradford force-pushed the cameronbaird/virtio-rtc branch from 9cfd3ea to cb61a7e Compare May 7, 2026 20:40

@phip1611 phip1611 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for bringing this up late but just yesterday I discovered a bug (#8163) and I think we have the same bug here!

Comment thread vmm/src/device_manager.rs Outdated
pci_common: PciDeviceCommonConfig {
id: Some(id.clone()),
iommu: self.force_access_platform,
..Default::default()

@phip1611 phip1611 May 8, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need the option to explicitly set the PCI BDF, similar to #8163. Should be a small addition to the PR. I'm just on my phone rn but it looks like this is missing.

This is important as management layers such as libvirt want the full control over the PCI BDFs.

If you do not have this, after a live migration, the device can have a different BDF (due to implicit BDF allocation) and is out of sync with the management layer. A guest could also be confused by the changed BDF.

@rbradford rbradford left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR needs a lot of changes to adapt to the virtio-devices changes that have recently been in and so will need a re-review.

@rbradford
rbradford marked this pull request as draft May 8, 2026 16:29
@Camelron

Camelron commented May 8, 2026

Copy link
Copy Markdown
Contributor Author

Alright, please give me a few days to take a look at the changes in the main branch and refactor things.

@rbradford

Copy link
Copy Markdown
Member

@Camelron Are you still pursuing this?

@Camelron
Camelron force-pushed the cameronbaird/virtio-rtc branch from cb61a7e to 17aae19 Compare May 18, 2026 23:10
@Camelron

Copy link
Copy Markdown
Contributor Author

@rbradford @phip1611 so sorry for the delay; this is not my main work and I fell far behind. See updated branch for review, it should be rebased and handle the explicit PCI BDFs via the RtcConfig.

@Camelron

Copy link
Copy Markdown
Contributor Author

CI is green so taking it back out of draft.

@Camelron
Camelron marked this pull request as ready for review May 18, 2026 23:34

@rbradford rbradford left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just the log (which I see -iommu and -mem are also like that). And then gtg.

Comment thread virtio-devices/src/rtc.rs
@Camelron
Camelron force-pushed the cameronbaird/virtio-rtc branch from 17aae19 to 4f77d2f Compare May 22, 2026 18:38
@Camelron

Copy link
Copy Markdown
Contributor Author

@phip1611 do you mind taking a look when you have the chance? Thank you.

@phip1611 phip1611 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your patience! LGTM!

Camelron added 2 commits May 26, 2026 09:52
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_MAYBE_SMEARED with leap_second_smearing
VIRTIO_RTC_SMEAR_UNSPECIFIED

The device is disabled by default, requiring --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 <[email protected]>
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 <[email protected]>
@Camelron
Camelron force-pushed the cameronbaird/virtio-rtc branch from 4f77d2f to 624dac1 Compare May 26, 2026 17:08
@Camelron

Copy link
Copy Markdown
Contributor Author

Doing one final rebase to get us back to green before merging. We got slightly out of sync of this change 44ed81e66 and I applied the same fix as for make_virtio_rng_devices to make_virtio_rtc_devices.

@phip1611 phip1611 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@liuw
liuw added this pull request to the merge queue May 26, 2026
Merged via the queue into cloud-hypervisor:main with commit f73eb3e May 26, 2026
41 checks passed
@github-project-automation github-project-automation Bot moved this from 🆕 New to ✅ Done in Cloud Hypervisor Roadmap Jul 8, 2026
@rbradford rbradford added the new-feature New feature to include in release notes label Jul 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

new-feature New feature to include in release notes

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

Implement a backend for virtio-rtc

7 participants