On Tue, Apr 10, 2018 at 09:23:53AM +0000, Liang, Cunming wrote:
> 
> 
> > -----Original Message-----
> > From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> > Sent: Tuesday, April 10, 2018 3:52 PM
> > To: Bie, Tiwei <tiwei....@intel.com>; Jason Wang <jasow...@redhat.com>
> > Cc: m...@redhat.com; alex.william...@redhat.com; ddut...@redhat.com;
> > Duyck, Alexander H <alexander.h.du...@intel.com>; virtio-dev@lists.oasis-
> > open.org; linux-ker...@vger.kernel.org; k...@vger.kernel.org;
> > virtualization@lists.linux-foundation.org; net...@vger.kernel.org; Daly, Dan
> > <dan.d...@intel.com>; Liang, Cunming <cunming.li...@intel.com>; Wang,
> > Zhihong <zhihong.w...@intel.com>; Tan, Jianfeng <jianfeng....@intel.com>;
> > Wang, Xiao W <xiao.w.w...@intel.com>
> > 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
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Reply via email to