virtio-devices: Implement a backend for virtio-rtc - #7795
Conversation
20490ff to
8071262
Compare
|
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. The consequence of this is that guest images may need udev rules to distinguish between them e.g. |
|
Does MSHV already have a paravirtualized timekeeping device? |
8071262 to
d9e65fd
Compare
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. |
|
Your PR and commit messages are missing a |
d6f64e8 to
76738c2
Compare
2ed954a to
12f98a9
Compare
12f98a9 to
ac105ed
Compare
|
FWIW - I did log in and delete the Image files from the workloads directory |
9cfd3ea to
cb61a7e
Compare
| pci_common: PciDeviceCommonConfig { | ||
| id: Some(id.clone()), | ||
| iommu: self.force_access_platform, | ||
| ..Default::default() |
There was a problem hiding this comment.
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
left a comment
There was a problem hiding this comment.
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.
|
Alright, please give me a few days to take a look at the changes in the main branch and refactor things. |
|
@Camelron Are you still pursuing this? |
cb61a7e to
17aae19
Compare
|
@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. |
|
CI is green so taking it back out of draft. |
rbradford
left a comment
There was a problem hiding this comment.
Just the log (which I see -iommu and -mem are also like that). And then gtg.
17aae19 to
4f77d2f
Compare
|
@phip1611 do you mind taking a look when you have the chance? Thank you. |
phip1611
left a comment
There was a problem hiding this comment.
Thanks for your patience! LGTM!
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]>
4f77d2f to
624dac1
Compare
|
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. |
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:
KVM guests can already use kvm_ptp which is synchronous
and therefore, more accurate.
Not implemented but theoretically supported by virtio-rtc is:
Fixes #7730