qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Tiwei Bie <tiwei.bie@intel.com>
To: virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org,
	mst@redhat.com, alex.williamson@redhat.com, pbonzini@redhat.com,
	stefanha@redhat.com
Cc: cunming.liang@intel.com, dan.daly@intel.com,
	jianfeng.tan@intel.com, zhihong.wang@intel.com,
	xiao.w.wang@intel.com, tiwei.bie@intel.com
Subject: [Qemu-devel] [RFC 0/3] Extend vhost-user to support VFIO based accelerators
Date: Fri, 22 Dec 2017 14:41:48 +0800	[thread overview]
Message-ID: <20171222064151.29266-1-tiwei.bie@intel.com> (raw)

This RFC patch set does some small extensions to vhost-user protocol
to support VFIO based accelerators, and makes it possible to get the
similar performance of VFIO passthru while keeping the virtio device
emulation in QEMU.

When we have virtio ring compatible devices, it's possible to setup
the device (DMA mapping, PCI config, etc) based on the existing info
(memory-table, features, vring info, etc) which is available on the
vhost-backend (e.g. DPDK vhost library). Then, we will be able to
use such devices to accelerate the emulated device for the VM. And
we call it vDPA: vhost DataPath Acceleration. The key difference
between VFIO passthru and vDPA is that, in vDPA only the data path
(e.g. ring, notify and queue interrupt) is pass-throughed, the device
control path (e.g. PCI configuration space and MMIO regions) is still
defined and emulated by QEMU.

The benefits of keeping virtio device emulation in QEMU compared
with virtio device VFIO passthru include (but not limit to):

- consistent device interface from guest OS;
- max flexibility on control path and hardware design;
- leveraging the existing virtio live-migration framework;

But the critical issue in vDPA is that the data path performance is
relatively low and some host threads are needed for the data path,
because some necessary mechanisms are missing to support:

1) guest driver notifies the device directly;
2) device interrupts the guest directly;

So this patch set does some small extensions to vhost-user protocol
to make both of them possible. It leverages the same mechanisms (e.g.
EPT and Posted-Interrupt on Intel platform) as the VFIO passthru to
achieve the data path pass through.

A new protocol feature bit is added to negotiate the accelerator feature
support. Two new slave message types are added to enable the notify and
interrupt passthru for each queue. From the view of vhost-user protocol
design, it's very flexible. The passthru can be enabled/disabled for
each queue individually, and it's possible to accelerate each queue by
different devices. More design and implementation details can be found
from the last patch.

There are some rough edges in this patch set (so this is a RFC patch
set for now), but it's never too early to hear the thoughts from the
community! So any comments and suggestions would be really appreciated!

Tiwei Bie (3):
  vhost-user: support receiving file descriptors in slave_read
  vhost-user: introduce shared vhost-user state
  vhost-user: add VFIO based accelerators support

 docs/interop/vhost-user.txt     |  57 ++++++
 hw/scsi/vhost-user-scsi.c       |   6 +-
 hw/vfio/common.c                |   2 +-
 hw/virtio/vhost-user.c          | 430 +++++++++++++++++++++++++++++++++++++++-
 hw/virtio/vhost.c               |   3 +-
 hw/virtio/virtio-pci.c          |   8 -
 hw/virtio/virtio-pci.h          |   8 +
 include/hw/vfio/vfio.h          |   2 +
 include/hw/virtio/vhost-user.h  |  43 ++++
 include/hw/virtio/virtio-scsi.h |   6 +-
 net/vhost-user.c                |  30 +--
 11 files changed, 561 insertions(+), 34 deletions(-)
 create mode 100644 include/hw/virtio/vhost-user.h

-- 
2.13.3

             reply	other threads:[~2017-12-22  6:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-22  6:41 Tiwei Bie [this message]
2017-12-22  6:41 ` [Qemu-devel] [RFC 1/3] vhost-user: support receiving file descriptors in slave_read Tiwei Bie
2017-12-22  6:41 ` [Qemu-devel] [RFC 2/3] vhost-user: introduce shared vhost-user state Tiwei Bie
2017-12-22  6:41 ` [Qemu-devel] [RFC 3/3] vhost-user: add VFIO based accelerators support Tiwei Bie
2018-01-16 17:23   ` Alex Williamson
2018-01-17  5:00     ` Tiwei Bie
2018-01-02  2:42 ` [Qemu-devel] [RFC 0/3] Extend vhost-user to support VFIO based accelerators Alexey Kardashevskiy
2018-01-02  5:49   ` Liang, Cunming
2018-01-02  6:01     ` Alexey Kardashevskiy
2018-01-02  6:48       ` Liang, Cunming
2018-01-03 14:34 ` [Qemu-devel] [virtio-dev] " Jason Wang
2018-01-04  6:18   ` Tiwei Bie
2018-01-04  7:21     ` Jason Wang
2018-01-05  6:58       ` Liang, Cunming
2018-01-05  8:38         ` Jason Wang
2018-01-05 10:25           ` Liang, Cunming
2018-01-08  3:23             ` Jason Wang
2018-01-08  8:23               ` [Qemu-devel] [virtio-dev] " Liang, Cunming
2018-01-08 10:06                 ` Jason Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171222064151.29266-1-tiwei.bie@intel.com \
    --to=tiwei.bie@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=cunming.liang@intel.com \
    --cc=dan.daly@intel.com \
    --cc=jianfeng.tan@intel.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=xiao.w.wang@intel.com \
    --cc=zhihong.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).