Crate Addition Request: vm-virtio

[sameo]

Crate Name

The virtio name is already taken on crates.io. The crate is unmaintained and really incomplete.

Instead of virtio, we could use:

• virtio-ng
• virtio-vmm
• Send your suggestion...

Short Description

This crate would provide:

• A VirtioDevice trait
• Implementations of VirtioDevice for the block, net, rng, ballon virtio devices
• Implementations of VirtioDevice for the vsock, and net vhost devices
• Virtio queues and descriptor API.
• MMIO and PCI virtio transports

Why is this crate relevant to the rust-vmm project?

rust-vmm needs a virtio implementation.

[andreeaflorescu]

virtio-devices looks free. we should indeed reserve the names.

[sameo]

cc @dgreid @jiangliu @dhrgit

[sameo]

virtio-devices looks free. we should indeed reserve the names.

I like virtio-devices.

[jiangliu]

virtio-devices: +1

[dagrh]

Do we get one crate with some different sections in it or multiple crates; for example do we have one that has just all the constant/structure/interface definitions in?

[andreeaflorescu]

We will probably have virtio-bindings or something of that sort for the kernel virtio headers. From my point of view the separation will come from the virtio device implementation vs the backends that you can use for those devices (the discussion about the backends is here: #20).

[jiangliu]

It would be great if the virtio-binding includes binding for vhost too, so the dependency relationship among virtio-device, vhost-backend and virtio-binding will be easy to maintain.

[andreeaflorescu]

@jiangliu how would it make it easier?

[jiangliu]

Just to maintain one less crate:) A dedicated vhost-binding crate should be OK too. Do you prefer a dedicated vhost-binding crate?

…

On Feb 15, 2019, at 12:19 AM, Andreea Florescu ***@***.*** ***@***.***>> wrote: @jiangliu <https://github.com/jiangliu> how would it make it easier? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB14_BaklvuIsM59C_PmLBG5spQs24Aqks5vNYx8gaJpZM4a7lwj>.

[andreeaflorescu]

I don't feel strongly for having it as a separate crate. I just thought it makes more sense to have 2 bindings for virtio-devices and vhost since we are going to have 2 crates to use those. On the other hand I wouldn't want to pollute rust-vmm with one binding crate for each feature as long as it makes sense to have them in a single crate. I really don't have a strong argument. Either way is good.

[bonzini]

Having a crate for virtio devices would first require defining a trait for devices (such as devices::bus), and I think that requires a separate design discussion.

However the crate could start porting to rust_vmm the devices::virtio::queue code for virtqueue parsing and devices::virtio::vhost code which can be used standalone.

[jiangliu]

Good suggestion to build a crate for device model.
The device model in crosvm and firecracker is not so strong, enhancements may be needed to support qemu and Kata container.

[liujing2]

@sameo Are we going to include all the device related into one crate? Instead of one crate for common codes like Bus, PCI and another one crate for real devices implementation.

[petreeftime]

As someone who is new to working with firecracker code but had to implement some virtio devices, I would want to see devices become quite a lot more generic than they are right now. The firecracker model does not really abstract KVM-specific design decisions all that well and this makes some things quite challenging to understand. I am not sure a single crate is a good idea, as that would lead to devices being less generic and more difficult to extend. The model behind rust-vmm in my opinion is to allow very slim and purposeful VMMs, and not a one-size-fits-all solution.

I can see a reason to separate devices into layers like: transport (PCI/MMIO), frontend (configuration of device and high-level handling of queues) and backend (handling of items in the queues for specific devices). This would allow sufficient separation to make it easy for someone to change the backend according to their needs, without having to dive too deeply into how the rest of the vmm is actually implemented.

I would see the following crates:

• virtio-device: this crate provides the generic traits required from a device to be counted as a virtio device
• virtio-mmio / virtio-pci: transport-specific functionality for devices.
• virtio-device-*: this is the default frontend + backend + backend traits for a specific virtio device. Although maybe it makes more sense to separate virtio-device-vsock for only frontend and have a separate virtio-device-vsock-vhost for the backend, even if the name is a bit verbose.

[bonzini]

virtio-device: this crate provides the generic traits required from a device to be counted as a virtio device

It can do much more: it can be a rust-vmm/vm-memory client that takes a dyn GuestMemory anddoes all the VirtQueue parsing. That should be the first thing to add, because it's the easiest to abstract - we already almost have vm-memory ready.

virtio-mmio / virtio-pci: transport-specific functionality for devices.

This depends on having device abstractions in rust-vmm, so it comes later.

[bonzini]

Let's rename this to virtio and start with virtqueue functionality, interfacing with vm-memory. Everything else (devices, which depend on the #33 vm-device create, vhost-kernel bindings, and vhost-user) can be added later and hidden behind features to keep the dependencies as small as possible.

[sboeuf]

@bonzini

Let's rename this to virtio

I think @sameo mentioned it's not possible because already used on crates.io.

[bonzini]

Why not vm-virtio, following vm-memory, vm-devices etc.?

[sboeuf]

Why not vm-virtio, following vm-memory, vm-devices etc.?

Fine by me, I like that we stay consistent with the naming.

[sameo]

I just created the vm-virtio repo.
I will shortly send an initial PR for it.
@bonzini iiuc you're suggesting we avoid having a virtio-bindings separate crate and use a cleaned up version of the bindgen'ed virtio code in the vm-virtio crate, right ?

[andreeaflorescu]

Repository created. Closing this issue.