Thanks for the post! I have one comment: On Mon, Sep 28, 2020 at 10:25:37AM +0100, Stefan Hajnoczi wrote: > Why extend vhost-user with vDPA? > ================================ > Reusing VIRTIO emulation code for vhost-user backends > ----------------------------------------------------- > It is a common misconception that a vhost device is a VIRTIO device. > VIRTIO devices are defined in the VIRTIO specification and consist of a > configuration space, virtqueues, and a device lifecycle that includes > feature negotiation. A vhost device is a subset of the corresponding > VIRTIO device. The exact subset depends on the device type, and some > vhost devices are closer to the full functionality of their > corresponding VIRTIO device than others. The most well-known example is > that vhost-net devices have rx/tx virtqueues and but lack the virtio-net > control virtqueue. Also, the configuration space and device lifecycle > are only partially available to vhost devices. > > This difference makes it impossible to use a VIRTIO device as a > vhost-user device and vice versa. There is an impedance mismatch and > missing functionality. That's a shame because existing VIRTIO device > emulation code is mature and duplicating it to provide vhost-user > backends creates additional work.
The biggest issue facing vhost-user and absent in vdpa is backend disconnect handling. This is the reason control path is kept under QEMU control: we do not need any logic to restore control path data, and we can verify a new backend is consistent with old one. > If there was a way to reuse existing VIRTIO device emulation code it > would be easier to move to a multi-process architecture in QEMU. Want to > run --netdev user,id=netdev0 --device virtio-net-pci,netdev=netdev0 in a > separate, sandboxed process? Easy, run it as a vhost-user-net device > instead of as virtio-net. Given vhost-user is using a socket, and given there's an elaborate protocol due to need for backwards compatibility, it seems safer to have vhost-user interface in a separate process too. -- MST
