Re: [PATCH RFC v3 0/6] Add Rust virtio bindings and sample device

[Manos Pitsidianakis <manos@pitsidianak.is>]

On Wed, 22 Jul 2026 12:31, Eugenio Perez Martin <eperezma@redhat.com> wrote:
>On Wed, Jul 22, 2026 at 11:04 AM Manos Pitsidianakis
><manos@pitsidianak.is> wrote:
>>
>> Hi Eugenio,
>>
>> On Wed, 22 Jul 2026 11:49, Eugenio Perez Martin <eperezma@redhat.com> wrote:
>> >On Tue, Jul 21, 2026 at 8:24 AM Manos Pitsidianakis
>> ><manos@pitsidianak.is> wrote:
>> >>
>> >> Ping.
>> >>
>> >> I have a different version of the series WIP with a virtio-rng instead
>> >> of virtio-rtc, based on
>> >> https://lore.kernel.org/lkml/20260529-rust-hw_random-virtio-rng-v1-0-b3153dd90311@pitsidianak.is/
>> >> (which needs a v2 also)
>> >>
>> >> But since this series hasn't gotten any feedback on the virtio part, I'd
>> >> like to ask if there is any before respinning.
>> >>
>> >> Thanks!
>> >>
>> >
>> >I also think this will be a great addition, but I have very little
>> >knowledge of Rust. Is it easy to implement the simplest virtio-net
>> >driver using Rust, without CVQ or extra features, so I can test it and
>> >hopefully build features on top? Would it help?
>>
>> I think so, however it would not be upstreamable right away since (I
>> think) there are no netdev Rust bindings and abstractions yet. I will
>> take a look when I have the time...
>>
>
>How about starting even smaller? Just with the virtio-ring processing
>that all virtio drivers share.

That's already possible with this series (adding inbufs/outbufs). If you 
mean a virtio-net that can react to virtio commands but does not do 
anything with packets, yes we can do that. I can try setting up a 
minimum driver we can work on together if you like.

Manos

>
>> (This is something I am also interested in because I'm working on a
>> different kind of network device)
>>
>> You can definitely play with the sample driver included in this series
>> however!
>>
>> Manos
>>
>>
>> >
>> >Thanks!
>> >
>> >> On Sun, 10 May 2026 16:38, Manos Pitsidianakis <manos@pitsidianak.is> 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?)
>> >> >
>> >> >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.
>> >> >- `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?
>> >> >- 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.
>> >> >- kernel::virtio module and its types need a few rustdoc examples that I
>> >> >  will add in followup series
>> >> >- Note that the registration of RTC clocks etc in the sample driver is
>> >> >  not done, I'm putting it off until I receive some feedback first. The
>> >> >  sample driver otherwise does send and receive data from the virtqueue
>> >> >  as a PoC.
>> >> >
>> >> >PS: No LLMs used so any mistakes and goofs are solely written by me.
>> >> >
>> >> >Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>
>> >> >---
>> >> >Changes in v3:
>> >> >- Removed unused methods from virtio API
>> >> >- Clean up how scattergather lists are added to virtqueues by using
>> >> >  owned SGTables only, and make the API safe(r)
>> >> >- Add RAII cleanup for find_vqs return value that calls del_vqs
>> >> >- Reset device after remove callback
>> >> >- Significantly clean up sample driver as a result of the other cleanups
>> >> >- Link to v2: https://lore.kernel.org/r/20260509-rust-virtio-v2-0-c1e30ec2bd21@pitsidianak.is
>> >> >
>> >> >Changes in v2:
>> >> >- Move helper ifdefs to helper file (thanks Alice)
>> >> >- Changed CONFIG checks to IS_ENABLED to allow for CONFIG_VIRTIO=m
>> >> >- Split all use imports to one item per line according to style guide
>> >> >- Fixed wait_for_completion_interruptible*() rustdocs
>> >> >- Use Jiffy type alias in wait_for_completion_interruptible_timeout()
>> >> >- Pepper and salt #[inline]s wherever appropriate as per style guide
>> >> >- Split probe() into probe() and init() to allow cleaning up if init
>> >> >  fails
>> >> >- Remove unnecessary Send and Sync unsafe impls for
>> >> >  kernel::virtio::Device
>> >> >- Remove unnecessary LeSize and BeSize
>> >> >- Accept Option<_> for virtqueue callback when creating a VirtqueueInfo
>> >> >- Made all vq buffer adding operations unsafe
>> >> >- Use AtomicU16 instead of Cell<u16> for sample virtio driver
>> >> >- Fix RespHead field types in sample virtio driver
>> >> >- Fix response error checking in sample virtio driver
>> >> >- Change some device contexts in method signatures
>> >> >- Link to v1: https://lore.kernel.org/r/20260505-rust-virtio-v1-0-9563383909e4@pitsidianak.is
>> >> >
>> >> >---
>> >> >Manos Pitsidianakis (6):
>> >> >      rust/bindings: generate virtio bindings
>> >> >      rust/helpers: add virtio.c
>> >> >      rust/kernel/device: return parent at same context
>> >> >      rust: add virtio module
>> >> >      rust: impl interruptible waits for Completion
>> >> >      samples/rust: Add sample virtio-rtc driver [WIP]
>> >> >
>> >> > MAINTAINERS                     |   9 +
>> >> > rust/bindings/bindings_helper.h |   5 +
>> >> > rust/helpers/helpers.c          |   1 +
>> >> > rust/helpers/virtio.c           |  37 ++++
>> >> > rust/kernel/device.rs           |   2 +-
>> >> > rust/kernel/lib.rs              |   2 +
>> >> > rust/kernel/sync/completion.rs  |  42 +++-
>> >> > rust/kernel/virtio.rs           | 423 ++++++++++++++++++++++++++++++++++++++++
>> >> > rust/kernel/virtio/utils.rs     |  57 ++++++
>> >> > rust/kernel/virtio/virtqueue.rs | 314 +++++++++++++++++++++++++++++
>> >> > samples/rust/Kconfig            |  15 ++
>> >> > samples/rust/Makefile           |   1 +
>> >> > samples/rust/rust_virtio_rtc.rs | 403 ++++++++++++++++++++++++++++++++++++++
>> >> > 13 files changed, 1309 insertions(+), 2 deletions(-)
>> >> >---
>> >> >base-commit: 028ef9c96e96197026887c0f092424679298aae8
>> >> >change-id: 20260504-rust-virtio-8523b01dfdc2
>> >> >
>> >> >Best regards,
>> >> >--
>> >> >Manos Pitsidianakis <manos@pitsidianak.is>
>> >> >
>>
>