Re: Outline for VHOST_USER_PROTOCOL_F_VDPA

["Michael S. Tsirkin" <mst@redhat.com>]

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