On 5/28/26 01:47, Manos Pitsidianakis wrote: > On Thu, May 28, 2026 at 8:22 AM Parav Pandit wrote: >> >> >>> From: Demi Marie Obenour >>> Sent: 28 May 2026 05:23 AM >>> To: virtio-comment@lists.linux.dev >>> Subject: MSI-X vector limits and reserving a virtio device ID >>> >>> I'd like to reserve a virtio device ID for virtio vhost-guest, >>> formally virtio vhost-user. Would this be possible? >>> >> Vhost user is an implementation of the device. >> I believe it stays as implementation and not a new device type. > > This exactly. > > Furthermore, we already have a mechanism for "providing" an arbitrary > virtio device; it's called a transport. > > Demi, I suggest you look into virtio-msg transport, which would allow > you to do what you want. I'm aware of virtio-msg, and in fact considered using it. However, I found that virtio-msg doesn't meet my requirements. 1. Virtio-msg needs to run over a transport of its own. None of the proposed transports support KVM guests on x86. FF-A is the only one that would make sense with KVM, but FF-A is specific to Arm. 2. Virtio-msg isn't compatible with existing frontend VMMs. Vhost-guest can be used with any frontend VMM that implements vhost-user. 3. Virtio-msg isn't compatible with existing frontend drivers. While I expect that drivers for Linux will eventually be upstreamed, I doubt that drivers for Windows or *BSD will ever be written. I don't even know if the Windows Driver Framework provides enough to write one. I don't need this myself, but I suspect that this is enough to make virtio-msg unsuitable in many environments. 4. Virtio-msg requires invasive changes to existing userspace device implementations. The project I work on doesn't use QEMU, and the existing frontends are targeted at server use-cases. Using the vhost-user protocol lets me reuse these with little effort. 5. To the best of my knowledge, virtio-msg doesn't support live migration of frontend VMs. Vhost-guest uses the vhost-user protocol, which has supported this for a very long time. I don't need live migration myself, but for many server use-cases, not having live migration is a dealbreaker. 6. I don't know if virtio-msg can achieve comparable performance. It appears to be optimized for reliability and isolation, not processing tens of gigabits of network traffic per second. Vhost-guest is designed with performance in mind. Vhost-guest is designed for storage and networking appliances on servers, whereas virtio-msg is designed for safety-critical embedded systems. These domains have very different requirements, and as a result they arrived at very different solutions. I work on Spectrum (https://spectrum-os.org), which uses Cloud Hypervisor. As the name implies, Cloud Hypervisor is primarily intended for cloud workloads, though it can also be used on clients. I don't think that an implementation of virtio-msg would be accepted, as it benefits none of Cloud Hypervisor's other users. -- Sincerely, Demi Marie Obenour (she/her/hers)