Re: [RFC] vhost: introduce mdev based hardware vhost backend

[Jason Wang <jasowang@redhat.com>]

On 2018年04月10日 12:57, Tiwei Bie wrote:
> On Tue, Apr 10, 2018 at 10:52:52AM +0800, Jason Wang wrote:
> > On 2018年04月02日 23:23, Tiwei Bie wrote:
> > > This patch introduces a mdev (mediated device) based hardware
> > > vhost backend. This backend is an abstraction of the various
> > > hardware vhost accelerators (potentially any device that uses
> > > virtio ring can be used as a vhost accelerator). Some generic
> > > mdev parent ops are provided for accelerator drivers to support
> > > generating mdev instances.
> > >
> > > What's this
> > > ===========
> > >
> > > The idea is that we can setup a virtio ring compatible device
> > > with the messages available at the vhost-backend. Originally,
> > > these messages are used to implement a software vhost backend,
> > > but now we will use these messages to setup a virtio ring
> > > compatible hardware device. Then the hardware device will be
> > > able to work with the guest virtio driver in the VM just like
> > > what the software backend does. That is to say, we can implement
> > > a hardware based vhost backend in QEMU, and any virtio ring
> > > compatible devices potentially can be used with this backend.
> > > (We also call it vDPA -- vhost Data Path Acceleration).
> > >
> > > One problem is that, different virtio ring compatible devices
> > > may have different device interfaces. That is to say, we will
> > > need different drivers in QEMU. It could be troublesome. And
> > > that's what this patch trying to fix. The idea behind this
> > > patch is very simple: mdev is a standard way to emulate device
> > > in kernel.
> > So you just move the abstraction layer from qemu to kernel, and you still
> > need different drivers in kernel for different device interfaces of
> > accelerators. This looks even more complex than leaving it in qemu. As you
> > said, another idea is to implement userspace vhost backend for accelerators
> > which seems easier and could co-work with other parts of qemu without
> > inventing new type of messages.
> I'm not quite sure. Do you think it's acceptable to
> add various vendor specific hardware drivers in QEMU?

I don't object but we need to figure out the advantages of doing it in 
qemu too.

Thanks