Today virtio backends are mostly living on the host. At KVM-Forum 2025
Stefano did a presentation [1] in which he mentioned the idea to have
virtio devices between a Coco guest and the associated SVSM. One problem
is to have a simple way to connect the virtio devices' frontends and
backends in a simple way.

A similar problem is existing when using virtio in a Xen environment:
Xen allows to use driver domains, so the backends can live in a mostly
unprivileged guest (this guest will probably need access to a physical
device like network, though).

With Xen it is possible to use Xenstore to communicate the configuration
of the virtio device: The Xen toolstack will write the configuration
related data to the backend- and frontend-specific paths in Xenstore for
the affected guests to pick them up.

With SVSM it would be possible to communicate the configuration via
SVSM-calls, but I believe we can do better.

I believe it would be interesting to add the concept of driver guests
to KVM, similar to the driver domains of Xen. This would add another
scenario where virtio parameters need to be communicated to guests. Here
hotplug (both sides, frontend and backend) needs to be considered, too.

With the introduction of a virtio config device most requirements could
be satisfied: it could enumerate available virtio devices, return config
parameters of a device (backend and frontend side), signal hotplugging of
new devices.

For the concept of driver guests those guests would need a way to access
I/O-buffers of the frontend side. Xen has the concept of grants for this
purpose, which is similar to a pv-IOMMU. It would be natural to use the
virtio IOMMU device for this purpose under KVM, probably with some extensions
for non-static use cases.

This is only a rough outline of the general idea. I'd be interested in any
feedback. If there is some interest of this concept, I'd be happy to start
working on a prototype for driver guests.


Juergen

[1]: https://gitlab.com/qemu-project/kvm-forum/-/raw/main/_attachments/2025/KVMForum_20_llGF8DH.pdf

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to