On Tue, Apr 10, 2018 at 09:23:53AM +0000, Liang, Cunming wrote: > > > > -----Original Message----- > > From: Paolo Bonzini [mailto:[email protected]] > > Sent: Tuesday, April 10, 2018 3:52 PM > > To: Bie, Tiwei <[email protected]>; Jason Wang <[email protected]> > > Cc: [email protected]; [email protected]; [email protected]; > > Duyck, Alexander H <[email protected]>; [email protected] > > open.org; [email protected]; [email protected]; > > [email protected]; [email protected]; Daly, Dan > > <[email protected]>; Liang, Cunming <[email protected]>; Wang, > > Zhihong <[email protected]>; Tan, Jianfeng <[email protected]>; > > Wang, Xiao W <[email protected]> > > 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. As others said, we do not need to go overeboard. A couple of small vendor-specific quirks in qemu isn't a big deal. > > > > Paolo
