vhost-user-generic: add support #7221

DemiMarie · 2025-07-25T02:22:14Z

This adds support for a generic vhost-user-generic device. All information about this device must be provided to Cloud Hypervisor via the command-line or API.

Fixes #7189

src/main.rs

rbradford · 2025-08-10T09:56:20Z

Can you give an example of what a vhost-user-generic device is?

DemiMarie · 2025-08-11T16:57:17Z

A vhost-user-generic device is a vhost-user device that is implemented entirely by the backend. All parameters, such as the maximum number of queues and the features, must be passed to Cloud Hypervisor via API or the command line. This allows using vhost-user devices that Cloud Hypervisor does not know about, such as sound or (in the future) GPU. It is also possible for other devices to wrap the vhost-user-generic implementation if they do not need any specific handling.

liuw · 2025-08-14T21:56:50Z

The QEMU patch referenced in #7189 -- https://lore.kernel.org/qemu-devel/20230901110018.3704459-1-alex.bennee@linaro.org/ -- shows that it is still in RFC status. What's the latest status in QEMU?

There is a flag VHOST_USER_PROTOCOL_F_PROBE defined in the QEMU patch, but that's not accepted. Your patches don't use that flag.

How will this work in practice? Do you have a working backend to support this already?

DemiMarie · 2025-08-15T01:43:43Z

The QEMU patch referenced in #7189 -- https://lore.kernel.org/qemu-devel/20230901110018.3704459-1-alex.bennee@linaro.org/ -- shows that it is still in RFC status. What's the latest status in QEMU?

I don’t think the patch was accepted. QEMU does have a generic vhost-user device, but (like this patch) it requires parameters to be passed by the user rather than fetching them from the backend. QEMU also requires a trivial source-code patch to enable the feature, which this patch doesn’t need.

There is a flag VHOST_USER_PROTOCOL_F_PROBE defined in the QEMU patch, but that's not accepted. Your patches don't use that flag.

You are correct. VHOST_USER_PROTOCOL_F_PROBE is needed to automatically obtain various information from the backend. This patch requires the information to be provided at device creation time instead.

How will this work in practice? Do you have a working backend to support this already?

This works with an unmodified virtiofsd, but the caller must explicitly provide all of the parameters needed. If I did not make any copy-and-paste mistakes, I used the following option to make a virtio-fs device:

--vhost-user-generic \
"socket=build/virtiofsd.sock,virtio_id=26,avail_features=$((0x5970000000)),avail_protocol_features=$((0x920b)),queue_size=1024,num_queues=1,min_queues=1,id=virtiofs0"

This interface is deliberately low-level to allow maximum flexibility. Callers are expected to know the parameters for their particular device. Higher-level tooling is expected to provide a user-friendly interface.

alyssais · 2025-11-21T07:48:23Z

Needs some clippy fixes.

This was breaking CI for PR cloud-hypervisor#7221. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

This breaks CI for cloud-hypervisor#7221. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

alyssais

Some proofreading issues in the commit message:

"vhost-user-vhost"
"generic vhost-user-generic device"

vmm/src/config.rs

virtio-devices/src/vhost_user/user_vhost_device.rs

vmm/src/device_manager.rs

virtio-devices/src/vhost_user/user_vhost_device.rs

alyssais · 2026-01-06T15:43:21Z

vmm/src/config.rs

+    pub const SYNTAX: &'static str = "virtio-vhost-user parameters \
+    \"virtio_id=<id>,socket=<socket_path>,num_queues=<number_of_queues>,\
+    queue_size=<size_of_each_queue>,id=<device_id>,pci_segment=<segment_id>,\
+    min_queues=<minimum_number_of_queues>,avail_features=<available features>\"";


I wouldn't! That's maintenance burden. If we find flexibility is needed later, it's a lot easier to add it then than it is to remove unnecessary flexibility down the line.

alyssais · 2026-01-06T15:44:11Z

vmm/src/config.rs

+        Ok(())
+    }
+
+    fn validate_always_identifier(


Let's rename it to something we understand, then?

vmm/src/config.rs

DemiMarie

I tested this with virtiofsd and it does not work. The culprit apepars to be configuration space access: the read_config and write_config functions are never called, as shown by a panic!() in them not triggering. Also, I have no idea how much config space is needed, so I don't know how much to save and restore. Therefore, I added a todo!() in the restore code.

Update: Cause of the problem was not adding the MetaVirtioDevice to the list of devices.

vmm/src/config.rs

DemiMarie · 2026-01-09T22:44:11Z

Culprit is commit a8d1411, which had an incompatible change to internal APIs.

DemiMarie · 2026-01-09T22:45:34Z

This is ready for review, but I do not expect migration to work. The reason is that the configuration space is not stored anywhere. I don’t know how large configuration space should be so I don’t know how large to make it.

It should always succeed and is apparently implicitly called by libc or some dependency somewhere. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

This adds support for a generic vhost-user-generic device. All information about this device must be provided to Cloud Hypervisor via the command-line or API. Allowing gettid() is needed to prevent seccomp violations. It has negligible attack surface. Fixes cloud-hypervisor#7189 Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

rbradford · 2026-01-11T10:15:04Z

This is ready for review, but I do not expect migration to work. The reason is that the configuration space is not stored anywhere. I don’t know how large configuration space should be so I don’t know how large to make it.

Great! I think we can still move forward with integrating but we will need to generate an error on an attempt to migrate.

alyssais · 2026-01-11T10:27:30Z

The reason is that the configuration space is not stored anywhere.

Given we just pass through configuration space reads and writes to the backend, wouldn't it be the responsibility of the backend to restore its configuration space when restarted?

alyssais · 2026-01-11T10:32:28Z

virtio-devices/src/vhost_user/user_vhost.rs

+                            .map_err(Error::VhostUserGetQueueMaxNum)?
+                            as usize
+                    } else {
+                        default_queues.into()


Wasn't this supposed to be inferred from the queue sizes? Why do we need another parameter? It's starting to feel like every time I look at this PR there's a new redundant way to specify the number of queues! 😅

rbradford · 2026-01-11T10:57:19Z

The reason is that the configuration space is not stored anywhere.

Given we just pass through configuration space reads and writes to the backend, wouldn't it be the responsibility of the backend to restore its configuration space when restarted?

Makes sense - let's just make sure that we don't get a silent failure when trying to migrate (I don't mind that migration is unsupported - I just don't want it to blow up on the destination, I think that's a bit user hostile!)

DemiMarie requested a review from a team as a code owner July 25, 2025 02:22

DemiMarie force-pushed the generic-vhost-user branch 6 times, most recently from aed497d to cd6b328 Compare July 26, 2025 02:33

alyssais reviewed Jul 26, 2025

View reviewed changes

src/main.rs Outdated Show resolved Hide resolved

DemiMarie marked this pull request as draft July 28, 2025 19:35

DemiMarie force-pushed the generic-vhost-user branch 4 times, most recently from b101b21 to 64b241c Compare August 8, 2025 01:13

DemiMarie force-pushed the generic-vhost-user branch 2 times, most recently from 2b46ed3 to 5c8e3f7 Compare August 9, 2025 17:54

DemiMarie force-pushed the generic-vhost-user branch from 5c8e3f7 to e084e44 Compare August 10, 2025 23:28

DemiMarie marked this pull request as ready for review August 11, 2025 04:26

alyssais mentioned this pull request Sep 4, 2025

README: clarify vhost-user-device-pci usage rust-vmm/vhost-device#868

Open

DemiMarie force-pushed the generic-vhost-user branch 3 times, most recently from 887cdc6 to 7cccee1 Compare September 10, 2025 10:05

alyssais mentioned this pull request Oct 30, 2025

rutabaga_gfx roadmap/discussion/collaboration magma-gpu/rutabaga_gfx#24

Open

DemiMarie force-pushed the generic-vhost-user branch from 7cccee1 to e8b8f38 Compare November 20, 2025 23:16

DemiMarie force-pushed the generic-vhost-user branch 2 times, most recently from 595b465 to 986efa7 Compare November 22, 2025 02:58

DemiMarie added a commit to DemiMarie/cloud-hypervisor that referenced this pull request Dec 31, 2025

hypervisor: Remove unneded unsafe block

514325a

This was breaking CI for PR cloud-hypervisor#7221. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

DemiMarie added a commit to DemiMarie/cloud-hypervisor that referenced this pull request Dec 31, 2025

hypervisor: Suppress unused_unsafe warning

f8ca3ea

This breaks CI for cloud-hypervisor#7221. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

DemiMarie added a commit to DemiMarie/cloud-hypervisor that referenced this pull request Dec 31, 2025

hypervisor: Suppress unused_unsafe warning

621f31a

This breaks CI for cloud-hypervisor#7221. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

DemiMarie mentioned this pull request Dec 31, 2025

hypervisor: Suppress unused_unsafe warning #7584

Merged

DemiMarie force-pushed the generic-vhost-user branch from c52ba0a to 298d2b4 Compare December 31, 2025 18:19

DemiMarie added a commit to DemiMarie/cloud-hypervisor that referenced this pull request Dec 31, 2025

hypervisor: Suppress unused_unsafe warning

38cb209

This breaks CI for cloud-hypervisor#7221. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

DemiMarie added a commit to DemiMarie/cloud-hypervisor that referenced this pull request Dec 31, 2025

hypervisor: Suppress unused_unsafe warning

04c5583

This breaks CI for cloud-hypervisor#7221. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

DemiMarie added a commit to DemiMarie/cloud-hypervisor that referenced this pull request Dec 31, 2025

hypervisor: Suppress unused_unsafe warning

87db6a9

This breaks CI for cloud-hypervisor#7221. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

DemiMarie added a commit to DemiMarie/cloud-hypervisor that referenced this pull request Jan 1, 2026

hypervisor: Suppress unused_unsafe warning

1536ec8

This breaks CI for cloud-hypervisor#7221. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

DemiMarie added a commit to DemiMarie/cloud-hypervisor that referenced this pull request Jan 1, 2026

hypervisor: Suppress unused_unsafe warning

4c3832f

This breaks CI for cloud-hypervisor#7221. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

DemiMarie added a commit to DemiMarie/cloud-hypervisor that referenced this pull request Jan 1, 2026

hypervisor: Suppress unused_unsafe warning

fe61553

This breaks CI for cloud-hypervisor#7221. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

DemiMarie force-pushed the generic-vhost-user branch from 298d2b4 to cb61104 Compare January 2, 2026 04:14

alyssais requested changes Jan 6, 2026

View reviewed changes

DemiMarie force-pushed the generic-vhost-user branch 2 times, most recently from 7e1c247 to a00688b Compare January 9, 2026 09:36

DemiMarie commented Jan 9, 2026

View reviewed changes

vmm/src/config.rs Show resolved Hide resolved

DemiMarie marked this pull request as draft January 9, 2026 09:39

DemiMarie requested a review from alyssais January 9, 2026 09:39

DemiMarie force-pushed the generic-vhost-user branch 2 times, most recently from a2cb9f0 to 17930d1 Compare January 9, 2026 22:44

DemiMarie marked this pull request as ready for review January 9, 2026 22:44

DemiMarie added 2 commits January 9, 2026 18:01

seccomp: Add gettid() to all seccomp filters

42a315b

It should always succeed and is apparently implicitly called by libc or some dependency somewhere. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

DemiMarie force-pushed the generic-vhost-user branch from 17930d1 to a85589c Compare January 9, 2026 23:02

alyssais requested changes Jan 11, 2026

View reviewed changes

vhost-user-generic: add support #7221

Are you sure you want to change the base?

vhost-user-generic: add support #7221

Uh oh!

Conversation

DemiMarie commented Jul 25, 2025

Uh oh!

Uh oh!

rbradford commented Aug 10, 2025

Uh oh!

DemiMarie commented Aug 11, 2025

Uh oh!

liuw commented Aug 14, 2025

Uh oh!

DemiMarie commented Aug 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alyssais commented Nov 21, 2025

Uh oh!

alyssais left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

alyssais Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

alyssais Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

DemiMarie left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

DemiMarie commented Jan 9, 2026

Uh oh!

DemiMarie commented Jan 9, 2026

Uh oh!

rbradford commented Jan 11, 2026

Uh oh!

alyssais commented Jan 11, 2026

Uh oh!

alyssais Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

rbradford commented Jan 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

DemiMarie commented Aug 15, 2025 •

edited

Loading

DemiMarie left a comment •

edited

Loading