feat(virtio): add generic vhost-user frontend device

[meAmitPatil]

Implement a generic vhost-user frontend device that is agnostic to the specific virtio device type being emulated. Unlike per-device-type frontends, this device delegates config space ownership entirely to the backend via the mandatory CONFIG protocol feature, allowing any virtio device type (e.g. virtio-fs, virtio-scsi) to be used without a
dedicated Firecracker frontend.

A VirtioDeviceType::VhostUserGeneric sentinel (0xFF) serves as the host-side MMIO map key, while a new mmio_device_type_id() trait method returns the real virtio type ID to the guest MMIO register. Queue count
is dynamic (Vec) since different device types need different configurations. Snapshotting is stubbed out, consistent with the existing vhost-user block device.

The device is configured via PUT /vhost-user-devices/{id} and tested end-to-end with virtiofsd — guest kernel recognises the device with the correct virtio type ID.

Closes #5687

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.

PR Checklist

• I have read and understand CONTRIBUTING.md.
• I have run tools/devtool checkbuild --all to verify that the PR passes
  build checks on all supported architectures.
• I have run tools/devtool checkstyle to verify that the PR passes the
  automated style checks.
• I have described what is done in these changes, why they are needed, and
  how they are solving the problem in a clear and encompassing way.
• I have updated any relevant documentation (both in code and in the docs)
  in the PR.
• I have mentioned all user-facing changes in CHANGELOG.md.
• If a specific issue led to this PR, this PR closes the issue.
• When making API changes, I have followed the
  Runbook for Firecracker API changes.
• I have tested all new and changed functionalities in unit tests and/or
  integration tests.
• I have linked an issue to every new TODO.

---

• This functionality cannot be added in rust-vmm.

[DemiMarie]

Is this a Firecracker limitation?

[meAmitPatil]

Hey, This is an implementation limitation, not a protocol one. The vhost-user protocol supports forwarding writes via VHOST_USER_SET_CONFIG. I deferred it since most backends (virtiofsd, SPDK) don't rely on guest-initiated config writes, and the existing vhost-user block device in Firecracker follows the same pattern. Happy to add it in this PR if you think it should be included.

[DemiMarie]

Before Firecracker is started, or before the device is attached? I’m guessing you mean the latter.

[meAmitPatil]

You're right, before the device is attached via the PUT /vhost-user-devices/{id} API call. Will fix the wording, thanks.

[ShadowCurse]

Hi @meAmitPatil, thank you for the PR. Unfortunately currently we don't have much bandwidth to give it a proper review, but after taking a quick look, it seems fine, but there are couple things to note:

• We will need integration tests for this like we do with vhost-user-block
• Since this is a generic device and it is very closely based on existing vhost-user-block, I think we should remove the duplication from existing vhost-user-block and use your generic backend for it instead.

[meAmitPatil]

Hi @meAmitPatil, thank you for the PR. Unfortunately currently we don't have much bandwidth to give it a proper review, but after taking a quick look, it seems fine, but there are couple things to note:

• We will need integration tests for this like we do with vhost-user-block
• Since this is a generic device and it is very closely based on existing vhost-user-block, I think we should remove the duplication from existing vhost-user-block and use your generic backend for it instead.

@ShadowCurse Thanks for taking a look! No worries on the review timeline. I've added integration tests. For the duplication refactor (using the generic backend for vhost-user-block), would you prefer that in this PR or as a
follow-up?

[ShadowCurse]

For the duplication refactor (using the generic backend for vhost-user-block), would you prefer that in this PR or as a follow-up?

I see 2 ways here:

1. Create generic impl first, use it for already existing vhost-user-block later (so the follow up PR strategy)
2. Modify existing vhost-user-block to use generic code under the hood first, then expose generic path as a new device

I think option 2 is better since it removes a point in time when there is a big duplication of the vhost related code. It will also force generic code to be instantly compatible with the existing block device (in 1. case there can be a redundant refactoring of new generic code if some assumptions in it do not hold for block device).

I think both of these steps can be done in a single PR. Or at least both changes can start in a single PR, and if needed, it should be easy enough to split them.