From patchwork Fri Jul 29 18:28:17 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Prerna Saxena X-Patchwork-Id: 9252761 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 196BF6075F for ; Fri, 29 Jul 2016 18:29:04 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0A27A283FE for ; Fri, 29 Jul 2016 18:29:04 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F268028405; Fri, 29 Jul 2016 18:29:03 +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.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID 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 66795283FE for ; Fri, 29 Jul 2016 18:29:03 +0000 (UTC) Received: from localhost ([::1]:32776 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTCWs-0008LU-Ib for patchwork-qemu-devel@patchwork.kernel.org; Fri, 29 Jul 2016 14:29:02 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34111) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTCWT-0008KG-Kt for qemu-devel@nongnu.org; Fri, 29 Jul 2016 14:28:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTCWS-0003Hp-BH for qemu-devel@nongnu.org; Fri, 29 Jul 2016 14:28:37 -0400 Received: from mail-pf0-x243.google.com ([2607:f8b0:400e:c00::243]:34038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTCWS-0003HX-1C for qemu-devel@nongnu.org; Fri, 29 Jul 2016 14:28:36 -0400 Received: by mail-pf0-x243.google.com with SMTP id g202so5863516pfb.1 for ; Fri, 29 Jul 2016 11:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Ys/Is3f88m+CCs6oGGtYxlbGVA1Ls0z8L13Oq492gVY=; b=gMSfEJzHzhYFpF31C37JPFgJjAD9QWf/G9YpeJqfk5hgXcR1tNKHkS6m5q3+9UwGSV dwNPgVHGyLl1WkvyD+M861f/tOSx+/OsKjaIvw5M+8auDIbKCI7kzFz1eNvMR95g6Vbw dK/qq7zSAmnnDPIXkRFv4XE5Tq0tkF2fLD/9vzwalLM1aYTRN8N4Tix1fsng3ogsF2XK mnY0rwAo14n4uc7bcUP9Vu1GU2r5hhbi4Q2vJ3nU2QigySVre9yMDBZORZ77YFrchp9f jTJMSYPQvQvnhXczrQyYbRVRtC80sy0RO6OWtSTkSb6I7VfTk3QvTD2lIPiuVH0txvYM HBlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Ys/Is3f88m+CCs6oGGtYxlbGVA1Ls0z8L13Oq492gVY=; b=IWrmnzY5sr/dTApHfXoe7OFTbjoXJPT3+96knIGEx2zWHyrjRLL7t1XwurA5VYJR8r JMfiQcIINy3mqz/HbN1LHnuFjR0WJB1lD0fgqHbyLvHAQVM5/mSfK6+BFd3EnkT3Rw02 thkD5fIO/igtwW+8pNlKo+SdPRBAMcvbKWac3WHqNyHyr3v/t6Egew/Bjs4CyG4MMtFa Xa2QFXmLUKCMNE/eSDZOIeYTJpNjSpIQpLQ0mc9yk5E9IFu2T5938BP2/diNrzDHJEwo 6d0mz+0OsXXGl73ZL4t4YD8HIpITulDuSsiikmcdigLz2FcdNxIHbwshaWNP2m67QMsw WaJw== X-Gm-Message-State: AEkooutEV/BjNMjOkRlBTTop7wOHOnhthv3XtEj5VJyN4uKl3J7D0LGytWQukiRr6SjSkA== X-Received: by 10.98.63.1 with SMTP id m1mr71294180pfa.14.1469816914919; Fri, 29 Jul 2016 11:28:34 -0700 (PDT) Received: from prerna-saxena.dev.eng.nutanix.com. (206-15-90-246.static.twtelecom.net. [206.15.90.246]) by smtp.gmail.com with ESMTPSA id s23sm26735853pfd.23.2016.07.29.11.28.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jul 2016 11:28:33 -0700 (PDT) From: Prerna Saxena To: qemu-devel@nongnu.org Date: Fri, 29 Jul 2016 11:28:17 -0700 Message-Id: <1469816898-32204-2-git-send-email-saxenap.ltc@gmail.com> X-Mailer: git-send-email 1.8.1.2 In-Reply-To: <1469816898-32204-1-git-send-email-saxenap.ltc@gmail.com> References: <1469816898-32204-1-git-send-email-saxenap.ltc@gmail.com> MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400e:c00::243 Subject: [Qemu-devel] [PATCH for-2.7 v6 1/2] vhost-user: Introduce a new protocol feature REPLY_ACK. 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: marcandre.lureau@redhat.com, Prerna Saxena , felipe@nutanix.com, anilkumar.boggarapu@nutanix.com, mst@redhat.com Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP From: Prerna Saxena This introduces the VHOST_USER_PROTOCOL_F_REPLY_ACK. If negotiated, client applications should send a u64 payload in response to any message that contains the "need_reply" bit set on the message flags. Setting the payload to "zero" indicates the command finished successfully. Likewise, setting it to "non-zero" indicates an error. Currently implemented only for SET_MEM_TABLE. Reviewed-by: Marc-André Lureau Signed-off-by: Prerna Saxena --- docs/specs/vhost-user.txt | 26 ++++++++++++++++++++++++++ hw/virtio/vhost-user.c | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 58 insertions(+) diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost-user.txt index 777c49c..57a8357 100644 --- a/docs/specs/vhost-user.txt +++ b/docs/specs/vhost-user.txt @@ -37,6 +37,8 @@ consists of 3 header fields and a payload: * 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 3 is the need_reply flag - see VHOST_USER_PROTOCOL_F_REPLY_ACK for + details. * Size - 32-bit size of the payload @@ -126,6 +128,8 @@ the ones that do: * VHOST_GET_VRING_BASE * VHOST_SET_LOG_BASE (if VHOST_USER_PROTOCOL_F_LOG_SHMFD) +[ Also see the section on REPLY_ACK protocol extension. ] + There are several messages that the master sends with file descriptors passed in the ancillary data: @@ -254,6 +258,7 @@ Protocol features #define VHOST_USER_PROTOCOL_F_MQ 0 #define VHOST_USER_PROTOCOL_F_LOG_SHMFD 1 #define VHOST_USER_PROTOCOL_F_RARP 2 +#define VHOST_USER_PROTOCOL_F_REPLY_ACK 3 Message types ------------- @@ -464,3 +469,24 @@ Message types is present in VHOST_USER_GET_PROTOCOL_FEATURES. The first 6 bytes of the payload contain the mac address of the guest to allow the vhost user backend to construct and broadcast the fake RARP. + +VHOST_USER_PROTOCOL_F_REPLY_ACK: +------------------------------- +The original vhost-user specification only demands replies for certain +commands. This differs from the vhost protocol implementation where commands +are sent over an ioctl() call and block until the client has completed. + +With this protocol extension negotiated, the sender (QEMU) can set the +"need_reply" [Bit 3] flag to any command. This indicates that +the client MUST respond with a Payload VhostUserMsg indicating success or +failure. The payload should be set to zero on success or non-zero on failure, +unless the message already has an explicit reply body. + +This indicates to QEMU that the requested operation has deterministically +been met or not. Today, QEMU is expected to terminate the main vhost-user +loop upon receiving such errors. In future, qemu could be taught to be more +resilient for selective requests. + +For the message types that already solicit a reply from the client, the +presence of VHOST_USER_PROTOCOL_F_REPLY_ACK or need_reply bit being set brings +no behaviourial change. (See the 'Communication' section for details.) diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c index 495e09f..521a5db 100644 --- a/hw/virtio/vhost-user.c +++ b/hw/virtio/vhost-user.c @@ -31,6 +31,7 @@ enum VhostUserProtocolFeature { VHOST_USER_PROTOCOL_F_MQ = 0, VHOST_USER_PROTOCOL_F_LOG_SHMFD = 1, VHOST_USER_PROTOCOL_F_RARP = 2, + VHOST_USER_PROTOCOL_F_REPLY_ACK = 3, VHOST_USER_PROTOCOL_F_MAX }; @@ -84,6 +85,7 @@ typedef struct VhostUserMsg { #define VHOST_USER_VERSION_MASK (0x3) #define VHOST_USER_REPLY_MASK (0x1<<2) +#define VHOST_USER_NEED_REPLY_MASK (0x1 << 3) uint32_t flags; uint32_t size; /* the following payload size */ union { @@ -158,6 +160,25 @@ fail: return -1; } +static int process_message_reply(struct vhost_dev *dev, + VhostUserRequest request) +{ + VhostUserMsg msg; + + if (vhost_user_read(dev, &msg) < 0) { + return -1; + } + + if (msg.request != request) { + error_report("Received unexpected msg type." + "Expected %d received %d", + request, msg.request); + return -1; + } + + return msg.payload.u64 ? -1 : 0; +} + static bool vhost_user_one_time_request(VhostUserRequest request) { switch (request) { @@ -239,11 +260,18 @@ static int vhost_user_set_mem_table(struct vhost_dev *dev, int fds[VHOST_MEMORY_MAX_NREGIONS]; int i, fd; size_t fd_num = 0; + bool reply_supported = virtio_has_feature(dev->protocol_features, + VHOST_USER_PROTOCOL_F_REPLY_ACK); + VhostUserMsg msg = { .request = VHOST_USER_SET_MEM_TABLE, .flags = VHOST_USER_VERSION, }; + if (reply_supported) { + msg.flags |= VHOST_USER_NEED_REPLY_MASK; + } + for (i = 0; i < dev->mem->nregions; ++i) { struct vhost_memory_region *reg = dev->mem->regions + i; ram_addr_t offset; @@ -277,6 +305,10 @@ static int vhost_user_set_mem_table(struct vhost_dev *dev, vhost_user_write(dev, &msg, fds, fd_num); + if (reply_supported) { + return process_message_reply(dev, msg.request); + } + return 0; }