From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59184) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL2tz-0000HH-Tt for qemu-devel@nongnu.org; Thu, 07 Jul 2016 02:35:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bL2tx-0002Jr-MY for qemu-devel@nongnu.org; Thu, 07 Jul 2016 02:35:10 -0400 Received: from mail-pf0-x243.google.com ([2607:f8b0:400e:c00::243]:33986) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL2tx-0002JJ-BB for qemu-devel@nongnu.org; Thu, 07 Jul 2016 02:35:09 -0400 Received: by mail-pf0-x243.google.com with SMTP id 66so960868pfy.1 for ; Wed, 06 Jul 2016 23:35:09 -0700 (PDT) From: Prerna Saxena Date: Wed, 6 Jul 2016 23:34:48 -0700 Message-Id: <1467873289-14220-2-git-send-email-saxenap.ltc@gmail.com> In-Reply-To: <1467873289-14220-1-git-send-email-saxenap.ltc@gmail.com> References: <1467873289-14220-1-git-send-email-saxenap.ltc@gmail.com> Subject: [Qemu-devel] [PATCH v3 1/2] vhost-user: Introduce a new protocol feature REPLY_ACK. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: felipe@nutanix.com, anilkumar.boggarapu@nutanix.com, mst@redhat.com, marcandre.lureau@gmail.com, Prerna Saxena 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_response" 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. Signed-off-by: Prerna Saxena --- docs/specs/vhost-user.txt | 44 ++++++++++++++++++++++++++++++++++++++++++++ hw/virtio/vhost-user.c | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 76 insertions(+) diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost-user.txt index 777c49c..26dbe71 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_response 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,42 @@ 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 responses 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 newly +introduced "need_response" [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. +In other words, response must be in the following format : + +------------------------------------ +| request | flags | size | payload | +------------------------------------ + + * Request: 32-bit type of the request + * Flags: 32-bit bit field: + * Size: size of the payload ( see below) + * Payload : a u64 integer, where a non-zero value indicates a failure. + +This aids debugging the application's responses from QEMU. More +importantly, it indicates to QEMU that the requested operation has +deterministically (not) been met. 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. + +Note that as per the original vhost-user protocol, the following four messages +anyway require distinct responses from the vhost-user client process: + * VHOST_GET_FEATURES + * VHOST_GET_PROTOCOL_FEATURES + * VHOST_GET_VRING_BASE + * VHOST_SET_LOG_BASE (if VHOST_USER_PROTOCOL_F_LOG_SHMFD) + +For these message types, the presence of VHOST_USER_PROTOCOL_F_REPLY_ACK or +need_response bit being set brings no behaviourial change. +The response from the client is identical whether or not the REPLY_ACK feature +has been negotiated. diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c index 495e09f..899f354 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_RESPONSE_MASK (0x1 << 3) uint32_t flags; uint32_t size; /* the following payload size */ union { @@ -107,6 +109,25 @@ static VhostUserMsg m __attribute__ ((unused)); /* The version of the protocol we support */ #define VHOST_USER_VERSION (0x1) +static int process_message_reply(struct vhost_dev *dev, + VhostUserRequest request) +{ + VhostUserMsg msg; + + if (vhost_user_read(dev, &msg) < 0) { + return 0; + } + + 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 ioeventfd_enabled(void) { return kvm_enabled() && kvm_eventfds_enabled(); @@ -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_RESPONSE_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; } -- 1.8.1.2