Re: [dpdk-dev] [RFC v1 0/2] Add device emulation support in DPDK

["Xia, Chenbo" <chenbo.xia@intel.com>]

Hi Thomas,

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, September 3, 2020 5:11 AM
> To: Xia, Chenbo <chenbo.xia@intel.com>
> Cc: dev@dpdk.org; Ding, Xuan <xuan.ding@intel.com>; Lu, Xiuchun
> <xiuchun.lu@intel.com>; Liang, Cunming <cunming.liang@intel.com>; Liu,
> Changpeng <changpeng.liu@intel.com>; Wang, Zhihong
> <zhihong.wang@intel.com>; Stephen Hemminger <stephen@networkplumber.org>;
> Richardson, Bruce <bruce.richardson@intel.com>; Burakov, Anatoly
> <anatoly.burakov@intel.com>; david.marchand@redhat.com;
> maxime.coquelin@redhat.com; matan@nvidia.com; Adrian Moreno
> <amorenoz@redhat.com>
> Subject: Re: [RFC v1 0/2] Add device emulation support in DPDK
> 
> 14/08/2020 21:16, Chenbo Xia:
> > Background & Motivation
> > -----------------------
> > In order to reduce the attack surface, QEMU community is disaggregating
> QEMU by
> > removing part of device emulation from it. The disaggregated/multi-
> process QEMU
> > is using VFIO-over-socket/vfio-user as the main transport mechanism to
> disaggregate
> > I/O services from QEMU[2]. Vfio-user essentially implements the VFIO
> device model
> > presented to the user process by a set of messages over a unix-domain
> socket. The
> > main difference between application using vfio-user and application
> using vfio
> > kernel module is that device manipulation is based on socket messages
> for vfio-user
> > but system calls for vfio kernel module. The vfio-user devices consist
> of a generic
> > VFIO device type, living in QEMU, which is called the client[3], and the
> core device
> > implementation (emulated device), living outside of QEMU, which is
> called the server.
> >
> > With the introduction and support of vfio-user in QEMU, QEMU is
> explicitly adding
> > support for external emulated device and data path. We are trying to
> leverage that
> > and introducing vfio-user support in DPDK. By doing so, DPDK is enabled
> to be an
> > alternative I/O device emulation library of building virtualized devices
> along with
> > high-performance data path in separate processes outside QEMU. It will
> be easy for
> > hardware vendors to provide virtualized solutions of their hardware
> devices by
> > implementing emulated device in DPDK.
> >
> > Except for vfio-user introduced in DPDK, this series also introduces the
> first
> > emulated device implementation. That is emulated AVF device (avf_emudev)
> implemented
> > by AVF emulation driver (avf_emudev driver). Emulated AVF device demos
> how emulated
> > device could be implemented in DPDK. SPDK is also investigating to
> implement use case
> > for NVMe.
> 
> I am completely unaware of this change in QEMU.
> I've found this presentation about Multi-process QEMU by Oracle:
> 	https://static.sched.com/hosted_files/kvmforum2019/d2/kvm-mpqemu.pdf
> and there is the wiki page you already referenced:
> 	https://wiki.qemu.org/Features/MultiProcessQEMU
> 
> I guess virtio stays inside QEMU?
> What is really moving out? e1000, ne2000 and vmxnet3?

Yes and it has not shown any impact on emulation of most existing devices.
AFAIK, one of the start point is NVMe.

> Why emulated AVF is needed, compared to a simple VFIO passthrough?

Emulated AVF is a show case of a specified virtual device, it's for para-virtualization
but not for HW device. Similar idea can apply on other virtual devices (e.g., memif).

Thanks!
Chenbo

> 
>