On 2018/11/9 上午12:48, Liang, Cunming wrote:
-----Original Message-----
From: Jason Wang [mailto:jasow...@redhat.com]
Sent: Thursday, November 8, 2018 2:16 AM
To: Liang, Cunming<cunming.li...@intel.com>; Wang, Xiao W
<xiao.w.w...@intel.com>;m...@redhat.com;alex.william...@redhat.com
Cc:qemu-devel@nongnu.org; Bie, Tiwei<tiwei....@intel.com>; Ye, Xiaolong
<xiaolong...@intel.com>; Wang, Zhihong<zhihong.w...@intel.com>; Daly, Dan
<dan.d...@intel.com>
Subject: Re: [RFC 0/2] vhost-vfio: introduce mdev based HW vhost backend


On 2018/11/7 下午11:08, Liang, Cunming wrote:
believe.
[LC] Agreed, so it reuses CMD defined by vhost-kernel ioctl. But
VFIO provides
device specific things (e.g. DMAR, INTR and etc.) which is the extra
APIs being introduced by this transport.


I'm not quite sure I understand here. I think having vhost-kernel
compatible ioctl does not conflict of using VFIO ioctl like DMA or INTR?

Btw, VFIO DMA ioctl is even not a must from my point of view,
vhost-mdev can forward the mem table information to device driver and
let it call DMA API to map/umap pages.
[LC] If not regarding vhost-mdev as a device, then forward mem table won't be a
concern.
If introducing a new mdev bus driver (vhost-mdev) which allows mdev instance to
be a new type of provider for vhost-kernel. It becomes a pretty good 
alternative to
fully leverage vhost-kernel ioctl.
I'm not sure it's the same view as yours when you says reusing vhost-kernel 
ioctl.

Yes it is.
[LC] It sounds a pretty good idea to me. Let us spend some time to figure out 
the next level detail, and sync-up further plan in community call.:)


Cool, thanks.


Reply via email to