[Feature Request] Generic vhost-user

[DemiMarie]

Feature Request

Implement a generic vhost-user frontend device. This is an alternative to #4266, which is specifically about vhost-user-blk.

Describe the desired solution

It is possible to implement a vhost-user frontend that knows very little about the specific device being implemented. When compared to per-device-type frontends, a generic frontend reduces the amount of code needed and allows using device types that Firecracker would never support natively. The only requirement is that the backend is responsible for handling configuration space.

This opens up many additional use-cases for Firecracker without adding any additional complexity on the Firecracker side. As shown by cloud-hypervisor/cloud-hypervisor#7221, the generic vhost-user frontend is roughly the same size as the other frontends, but offers much more functionality. For instance, it can be used with SPDK’s vhost-user-blk backend or with virtiofsd.

Describe possible alternatives

Implement separate frontends for each supported vhost-user device type. This needs more code and is less flexible.

Additional context

I saw that #4266 was about implementing a vhost-user-blk frontend. As demonstrated by cloud-hypervisor/cloud-hypervisor#7221, a generic vhost-user frontend would support more device types, while possibly requiring less code.

Checks

• Have you searched the Firecracker Issues database for similar requests?
• Have you read all the existing relevant Firecracker documentation?
• Have you read and understood Firecracker's core tenets?

[ilstam]

Hi Demi Marie,

Thanks for the feature request.

The proposal seems reasonable. We might not be able to get to this soon, but we are always happy to review external contributions and/or help with any questions or design concerns.

Thanks.

[ankushT369]

I want to work on this can u assign this to me.

[Manciukic]

Hey @ankushT369,

thanks for the interest. The proposal from Demi Marie seems reasonable, but I don't think there's anything more concrete than that at the moement. We're happy to see a PoC, or help on a design, and then decide based on that whether we want to integrate it. There is no guarantee any work on this will be merged at the moment.
Also note that there is currently some rework happening on the device space, so there will probably be quite some rebasing to do for this.

Thanks,
Riccardo

[ankushT369]

Hey @ankushT369,

thanks for the interest. The proposal from Demi Marie seems reasonable, but I don't think there's anything more concrete than that at the moement. We're happy to see a PoC, or help on a design, and then decide based on that whether we want to integrate it. There is no guarantee any work on this will be merged at the moment. Also note that there is currently some rework happening on the device space, so there will probably be quite some rebasing to do for this.

Thanks, Riccardo

@Manciukic thanks for replying. It’s ok!! But yeah, I’ll come up with my own design. Also, since I’m learning Firecracker and how it works under the hood, if there are any other issues I can help with, I’d be happy to do that.

[Manciukic]

I don't think this is a good first time issue. You may want to look into issues with the "Good first time issue" flag. One we stumbled upon recently was adding ACPI PM for supporting graceful poweroff from within x86 guests #1601

[ankushT369]

@Manciukic thanks

[meAmitPatil]

Hi, I've been working on a PoC implementation for this. It follows the approach from cloud-hypervisor's generic vhost-user device (cloud-hypervisor/cloud-hypervisor#7221) and builds on the existing vhost-user block frontend patterns in Firecracker.

Key design decisions:

• New VirtioDeviceType::VhostUserGeneric (0xFF) sentinel used as the host-side MMIO map key, while a separate device_type_id field holds the real virtio type ID written to the guest-visible MMIO register (via a new
  mmio_device_type_id () trait method)
• CONFIG protocol feature is mandatory, the backend owns the config space entirely
• Dynamic queue count (Vec, not fixed array) since different device types need different queue configurations
• Snapshotting is stubbed out (returns error), consistent with vhost-user block
• API endpoint: PUT /vhost-user-devices/{id}

Tested end-to-end with virtiofsd - guest kernel sees the device with the correct virtio type ID.

Happy to open a PR if you'd like to review the implementation. Also happy to adjust the design based on any feedback.