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

From: Jason Wang
Date: Tue Apr 10 2018 - 22:18:28 EST




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