On Mon, Sep 28, 2020 at 03:21:56PM +0400, Marc-André Lureau wrote: > On Mon, Sep 28, 2020 at 1:25 PM Stefan Hajnoczi <stefa...@redhat.com wrote: > > Where this converges with multi-process QEMU > > -------------------------------------------- > > At this point QEMU can run ad-hoc vhost-user backends using existing > > VIRTIO device models. It is possible to go further by creating a > > qemu-dev launcher executable that implements the vhost-user spec's > > "Backend program conventions". This way a minimal device emulator > > executable hosts the device instead of a full system emulator. > > > > The requirements for this are similar to the multi-process QEMU effort, > > which aims to run QEMU devices as separate processes. One of the main > > open questions is how to design build system and Kconfig support for > > building minimal device emulator executables. > > > > In the case of vhost-user-net the qemu-dev-vhost-user-net executable > > would contain virtio-net-device, vhost-user-backend, any netdevs the > > user wishes to include, a QMP monitor, and a vhost-user backend > > command-line interface. > > > > Where does this leave us? QEMU's existing VIRTIO device models can be > > used as vhost-user devices and run in a separate processes from the VMM. > > It's a great way of reusing code and having the flexibility to deploy it > > in the way that makes most sense for the intended use case. > > > > My understanding is that this would only be able to expose virtio > devices from external processes. But vfio-user could expose more kinds > of devices, including the virtio devices. > > Shouldn't we focus on vfio-user now, as the general out-of-process > device solution?
Eventually vfio-user can replace vhost-user. However, vfio-user development will take longer so for anyone already comfortable with vhost-user I think extending the protocol with vDPA ioctls is attractive. Maybe we can get more organized around vfio-user and make progress quicker? Stefan
signature.asc
Description: PGP signature
