Dan<dan.d...@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 Tue, Apr 10, 2018 at 09:23:53AM +, Liang,
.@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 abst
On Tue, Apr 10, 2018 at 09:23:53AM +, Liang, Cunming wrote:
> 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.
There is already an NVMe VFIO
> From: Liang, Cunming
> Sent: Tuesday, April 10, 2018 10:24 PM
>
[...]
> >
> > As others said, we do not need to go overeboard. A couple of small
> vendor-
> > specific quirks in qemu isn't a big deal.
>
> It's quite challenge to identify it's small or not, there's no uniform metric.
>
> It's
er.kernel.org; Daly, Dan <dan.d...@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
>
&g
oundation.org; netdev@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>
> > Subj
el.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 wr
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
