On Sun, May 10, 2026 at 04:38:13PM +0300, Manos Pitsidianakis wrote:
Hi all, this RFC series adds Rust bindings for Virtio drivers
(frontends in virtio parlance).
As a PoC, it also adds a sample virtio-rtc driver which performs
capability discovery through the virtqueue without registering any clock.
Before I send a cleaned-up non-RFC I would like some initial feedback
(i.e. is it something the upstream wants?)
I had a quick look, I commented something, but maybe you already planned
to fix some of them in the final version.
That said, overall it seems a great starting point, and I can help with
the effort of maintaining it.
I had some issues building the rust virtio rtc driver, it seems bindgen
0.71.1 I had installed have some issues with clang 22, upgrading bindgen
to 0.72 fixed all the issues.
This was tested with the rust-vmm vhost-device-rtc device backend that I
wrote[^0]:
[^0]:
https://github.com/rust-vmm/vhost-device/tree/main/vhost-device-rtc
Instructions:
Run the daemon in a separate terminal:
$ cargo run --bin vhost-device-rtc -- -s /tmp/rtc.sock
Then run the VM:
$ qemu-system-aarch64 \
-machine type=virt,virtualization=off,acpi=on \
-cpu host \
-smp 8 \
-accel kvm \
-drive if=virtio,format=qcow2,file=./debian-13-nocloud-arm64-daily.qcow2 \
-device virtio-net-pci,netdev=unet \
-device virtio-scsi-pci \
-serial mon:stdio \
-m 8192 \
-object memory-backend-memfd,id=mem,size=8G,share=on \
-numa node,memdev=mem \
-display none \
-vga none \
-kernel /path/to/linux/build/arch/arm64/boot/Image \
-device
vhost-user-test-device,chardev=rtc,id=rtc,virtio-id=17,num_vqs=2,vq_size=1024 \
-chardev socket,path=/tmp/rtc.sock,id=rtc \
...
Example output:
[ 1.105238] rust_virtio_rtc: Probe Rust virtio driver sample.
[ 1.105645] rust_virtio_rtc: Found 1 vqs.
[ 1.136050] rust_virtio_rtc: process_requestq got buf 16 bytes
[ 1.136125] rust_virtio_rtc: Got response! Ok(RespCfg { head: ReqHead {
msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, num_clocks: Le16(3),
reserved: [0, 0, 0, 0, 0, 0] })
[ 1.136701] rust_virtio_rtc: Got response! Ok(RespClockCap {
head: ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] },
clock_type: 3, leap_second_smearing: 0, flags: 0, reserved: [0, 0,
0, 0, 0] })
[ 1.136724] rust_virtio_rtc virtio0: cannot expose clock 0 (type 3,
variant 0, flags 0) to userspace
[ 1.137259] rust_virtio_rtc: Got response! Ok(RespRead { head: ReqHead {
msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_reading:
Le64(1777890485031060388) })
[ 1.137277] rust_virtio_rtc: #0 clock reading =
1777890485031060388
[ 1.137749] rust_virtio_rtc: Got response! Ok(RespClockCap { head:
ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_type: 1,
leap_second_smearing: 0, flags: 0, reserved: [0, 0, 0, 0, 0] })
[ 1.137769] rust_virtio_rtc virtio0: cannot expose clock 1 (type 1,
variant 0, flags 0) to userspace
[ 1.138247] rust_virtio_rtc: Got response! Ok(RespRead { head: ReqHead {
msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_reading:
Le64(1777890485032086075) })
[ 1.138264] rust_virtio_rtc: #1 clock reading = 1777890485032086075
[ 1.138730] rust_virtio_rtc: Got response! Ok(RespClockCap { head:
ReqHead { msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_type: 2,
leap_second_smearing: 0, flags: 0, reserved: [0, 0, 0, 0, 0] })
[ 1.138751] rust_virtio_rtc virtio0: cannot expose clock 2 (type 2,
variant 0, flags 0) to userspace
[ 1.139253] rust_virtio_rtc: Got response! Ok(RespRead { head: ReqHead {
msg_type: Le16(0), reserved: [0, 0, 0, 0, 0, 0] }, clock_reading:
Le64(338567896865557) })
[ 1.139270] rust_virtio_rtc: #2 clock reading = 338567896865557
Concerns - Notes - TODOs
========================
- Virtqueue lifetimes don't neatly apply to Rust as expected, so a lot
of times we have to go through unsafe pointer dereferences (though
which are guaranteed by Virtio subsystem to be valid, for example
when
a callback is called with the vq argument). There's a potential for
misuse and definitely could use better thinking.
Yeah, I see, I guess we can work on this as next step.
I'm CCing Matteo, German, Giuseppe, and Leonardo.
We are mentoring Matteo who is working on his Master thesis at University
of Pisa. His main effort is to provide crates for virtio drivers (e.g.
virtqueue, driver-specific request/reply processing, etc.) that can be
generic enough to be used in different OSes, providing the right
abstraction.
We pointed out to this series and he would like to collaborate.
Matteo and others can add more on this of course :-)
Feel free to continue in-list or off-list for sync.
- `struct virtio_device` is not reference-counted like other implemented
device types in rust/kernel. Maybe we need to change C API first to
make them reference counted, assuming this doesn't break anything?
Good point.
- The sample driver obviously conflicts with the C implementation, so
this would either need to move out of samples/ or figure out some way
to handle this in kbuild.
I think we need to discuss this with MST, but IMO we should try the path
of replacing the C version with this (when we feel confident).
- kernel::virtio module and its types need a few rustdoc examples that I
will add in followup series
Agree.
Thanks,
Stefano
