From patchwork Thu Nov 24 03:20:57 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Wang, Wei W" X-Patchwork-Id: 9444729 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 398BB60779 for ; Thu, 24 Nov 2016 03:21:32 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 325B0276D6 for ; Thu, 24 Nov 2016 03:21:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2707927C2D; Thu, 24 Nov 2016 03:21:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id B32A1276D6 for ; Thu, 24 Nov 2016 03:21:31 +0000 (UTC) Received: from localhost ([::1]:37685 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9kbK-0002K4-PC for patchwork-qemu-devel@patchwork.kernel.org; Wed, 23 Nov 2016 22:21:30 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9kak-0002IC-Fg for qemu-devel@nongnu.org; Wed, 23 Nov 2016 22:20:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9kai-0005CO-S1 for qemu-devel@nongnu.org; Wed, 23 Nov 2016 22:20:54 -0500 Received: from mga05.intel.com ([192.55.52.43]:7824) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c9kai-0005Bk-FF for qemu-devel@nongnu.org; Wed, 23 Nov 2016 22:20:52 -0500 Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP; 23 Nov 2016 19:20:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,690,1473145200"; d="scan'208";a="34962146" Received: from devel-ww.sh.intel.com ([10.239.48.106]) by orsmga005.jf.intel.com with ESMTP; 23 Nov 2016 19:20:49 -0800 From: Wei Wang To: marcandre.lureau@gmail.com, mst@redhat.com, stefanha@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, virtio-comment@lists.oasis-open.org Date: Wed, 23 Nov 2016 22:20:57 -0500 Message-Id: <1479957659-141601-3-git-send-email-wei.w.wang@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1479957659-141601-1-git-send-email-wei.w.wang@intel.com> References: <1479957659-141601-1-git-send-email-wei.w.wang@intel.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 192.55.52.43 Subject: [Qemu-devel] [PATCH v2 2/4] spec/vhost-user: extend vhost-user to support the vhost-pci based inter-vm communiaction X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Wei Wang Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP The protocol feature, VHOST_USER_PROTOCOL_F_VHOST_PCI, indicates the support of vhost-pci. With the vhost-pci extension, the slave may actively sending meesages to the master. VHOST_USER_SET_FEATURES is one of the examples. To understand this example, let's first understand how the device feature bits are negotiated between the slave device/driver and the master device/driver: 1) the master device (e.g. virtio-net) GET_FEATURES from the slave (assume the feature bits are "f1"); 2) the master device negotiates the feature bits with its driver (assume the device gets "f2" after the negotiation); 3) the master device SET_FEATURES("f2") to the slave; 4) the slave creates a slave device (e.g. vhost-pci-net) with "f2" and the slave device negotiates "f2" with its driver (assume the device gets "f3" after the negotiation); 5) the slave _actively_ SET_FEATURES("f3") to the master device; 6) if "f3" != "f2", the master device needs to perform a device reset and re-negotiate the feature bits with its driver using "f3". Signed-off-by: Wei Wang --- docs/specs/vhost-user.txt | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost-user.txt index d70bd83..3bbe641 100644 --- a/docs/specs/vhost-user.txt +++ b/docs/specs/vhost-user.txt @@ -17,12 +17,15 @@ The protocol defines 2 sides of the communication, master and slave. Master is the application that shares its virtqueues, in our case QEMU. Slave is the consumer of the virtqueues. -In the current implementation QEMU is the Master, and the Slave is intended to +In the traditional implementation QEMU is the master, and the slave is intended to be a software Ethernet switch running in user space, such as Snabbswitch. Master and slave can be either a client (i.e. connecting) or server (listening) in the socket communication. +The current vhost-user protocol is extended to support the vhost-pci based inter-VM +communication. In this case, both the slave and master are QEMU instances. + Message Specification --------------------- @@ -36,7 +39,7 @@ consists of 3 header fields and a payload: * Request: 32-bit type of the request * Flags: 32-bit bit field: - Lower 2 bits are the version (currently 0x01) - - Bit 2 is the reply flag - needs to be sent on each reply from the slave + - Bit 2 is the reply flag - needs to be sent on each reply - Bit 3 is the need_reply flag - see VHOST_USER_PROTOCOL_F_REPLY_ACK for details. * Size - 32-bit size of the payload @@ -119,9 +122,9 @@ The protocol for vhost-user is based on the existing implementation of vhost for the Linux Kernel. Most messages that can be sent via the Unix domain socket implementing vhost-user have an equivalent ioctl to the kernel implementation. -The communication consists of master sending message requests and slave sending -message replies. Most of the requests don't require replies. Here is a list of -the ones that do: +Traditionally, the communication consists of master sending message requests and +slave sending message replies. Most of the requests don't require replies. Here +is a list of the ones that do: * VHOST_USER_GET_FEATURES * VHOST_USER_GET_PROTOCOL_FEATURES @@ -130,6 +133,10 @@ the ones that do: [ Also see the section on REPLY_ACK protocol extension. ] +Currently, the communication also supports the slave actively sending messages +to the master. Here is a list of them: + * VHOST_USER_SET_FEATURES + There are several messages that the master sends with file descriptors passed in the ancillary data: @@ -259,6 +266,7 @@ Protocol features #define VHOST_USER_PROTOCOL_F_LOG_SHMFD 1 #define VHOST_USER_PROTOCOL_F_RARP 2 #define VHOST_USER_PROTOCOL_F_REPLY_ACK 3 +#define VHOST_USER_PROTOCOL_F_VHOST_PCI 4 Message types ------------- @@ -279,6 +287,7 @@ Message types Id: 2 Ioctl: VHOST_SET_FEATURES Master payload: u64 + Slave payload: u64 Enable features in the underlying vhost implementation using a bitmask. Feature bit VHOST_USER_F_PROTOCOL_FEATURES signals slave support for