Re: [virtio-dev] Re: [RFC] vhost: introduce mdev based hardware vhost backend

[Jason Wang]

On 2018å04æ10æ 22:23, Liang, Cunming wrote:
> > -----Original Message-----
> > From: Michael S. Tsirkin [mailto:mst@xxxxxxxxxx]
> > Sent: Tuesday, April 10, 2018 9:36 PM
> > To: Liang, Cunming<cunming.liang@xxxxxxxxx>
> > Cc: Paolo Bonzini<pbonzini@xxxxxxxxxx>; Bie, Tiwei<tiwei.bie@xxxxxxxxx>;
> > Jason Wang<jasowang@xxxxxxxxxx>;alex.williamson@xxxxxxxxxx;
> > ddutile@xxxxxxxxxx; Duyck, Alexander H<alexander.h.duyck@xxxxxxxxx>;
> > virtio-dev@xxxxxxxxxxxxxxxxxxxx;linux-kernel@xxxxxxxxxxxxxxx;
> > kvm@xxxxxxxxxxxxxxx;virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx;
> > netdev@xxxxxxxxxxxxxxx; Daly, Dan<dan.daly@xxxxxxxxx>; Wang, Zhihong
> > <zhihong.wang@xxxxxxxxx>; Tan, Jianfeng<jianfeng.tan@xxxxxxxxx>; Wang, Xiao
> > W<xiao.w.wang@xxxxxxxxx>
> > Subject: Re: [virtio-dev] Re: [RFC] vhost: introduce mdev based hardware vhost
> > backend
> >
> > On Tue, Apr 10, 2018 at 09:23:53AM +0000, Liang, Cunming wrote:
> > > > -----Original Message-----
> > > > From: Paolo Bonzini [mailto:pbonzini@xxxxxxxxxx]
> > > > Sent: Tuesday, April 10, 2018 3:52 PM
> > > > To: Bie, Tiwei<tiwei.bie@xxxxxxxxx>; Jason Wang
> > > > <jasowang@xxxxxxxxxx>
> > > > Cc:mst@xxxxxxxxxx;alex.williamson@xxxxxxxxxx;ddutile@xxxxxxxxxx;
> > > > Duyck, Alexander H<alexander.h.duyck@xxxxxxxxx>;
> > > > virtio-dev@xxxxxxxxxxxx open.org;linux-kernel@xxxxxxxxxxxxxxx;
> > > > kvm@xxxxxxxxxxxxxxx;virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx;
> > > > netdev@xxxxxxxxxxxxxxx; Daly, Dan<dan.daly@xxxxxxxxx>; Liang,
> > > > Cunming<cunming.liang@xxxxxxxxx>; Wang, Zhihong
> > > > <zhihong.wang@xxxxxxxxx>; Tan, Jianfeng<jianfeng.tan@xxxxxxxxx>;
> > > > Wang, Xiao W<xiao.w.wang@xxxxxxxxx>
> > > > Subject: Re: [virtio-dev] Re: [RFC] vhost: introduce mdev based
> > > > hardware vhost backend
> > > >
> > > > On 10/04/2018 06:57, Tiwei Bie wrote:
> > > > > > 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 think so.  We have vendor-specific quirks, and at some point there
> > > > was an idea of using quirks to implement (vendor-specific) live
> > > > migration support for assigned devices.
> > > Vendor-specific quirks of accessing VGA is a small portion. Other major portions
> > are still handled by guest driver.
> > > While in this case, when saying various vendor specific drivers in QEMU, it says
> > QEMU takes over and provides the entire user space device drivers. Some parts
> > are even not relevant to vhost, they're basic device function enabling. Moreover,
> > it could be different kinds of devices(network/block/...) under vhost. No matter
> > # of vendors or # of types, total LOC is not small.
> > > The idea is to avoid introducing these extra complexity out of QEMU, keeping
> > vhost adapter simple. As vhost protocol is de factor standard, it leverages kernel
> > device driver to provide the diversity. Changing once in QEMU, then it supports
> > multi-vendor devices whose drivers naturally providing kernel driver there.
> > > If QEMU is going to build a user space driver framework there, we're open mind
> > on that, even leveraging DPDK as the underlay library. Looking forward to more
> > others' comments from community.
> > > Steve
> > Dependency on a kernel driver is fine IMHO. It's the dependency on a DPDK
> > backend that makes people unhappy, since the functionality in question is setup-
> > time only.
> Agreed, we don't see dependency on kernel driver is a problem.

At engineering level, kernel driver is harder than userspace driver.

> mdev based vhost backend (this patch set) is independent with vhost-user extension patch set. In fact, there're a few vhost-user providers, DPDK librte_vhost is one of them. FD.IO/VPP and snabbswitch have their own vhost-user providers. So I can't agree on vhost-user extension patch depends on DPDK backend. But anyway, that's the topic of another mail thread.

Well we can treat mdev as another kind of transport of vhost-user. And 
technically we can even implement a relay mdev than forward vhost-user 
messages to dpdk.

Thanks