From nobody Fri May 17 06:54:20 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1615458871; cv=none; d=zohomail.com; s=zohoarc; b=iU+qPgEuP68wQAusievzC8qqt0x3fO/CO2VPqmBq678bulDyudZGDet8eavqRZzeU8XrhZJ4hMpb9b0DgEP5XI5UAwIxLp/dQeHqRWXE7rX4zMNBJGVZDWJjhhH87wRfkD0YZJUc5IXwPx0vF3tKRp79JoGg5+6PLySOwFq0CKs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1615458871; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=/99h6TfCR3pAsmKhZm5mKjTif2mO+t7aYAaYGvoa9JI=; b=gnGHc7kty5iFMbdzeMIF3fiX0mDdC6OPFlArw8t2Tw4KajYbzN+al5ZVPjRiydRHV2Qugr52Pn8iGhAO14AfjtgXo2qEwRsuTn7UKU077EBnNPMoZJdu/UBdtcI0G1PDlSaTc4EpKdMJDwEJOTn9trO8HBhbLvl+vO4+kXEOY10= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1615458871442943.4873620606018; Thu, 11 Mar 2021 02:34:31 -0800 (PST) Received: from localhost ([::1]:40076 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKIeE-0004Pm-0E for importer@patchew.org; Thu, 11 Mar 2021 05:34:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46864) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lKIcv-0002Yb-J2 for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:33:09 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:59867) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lKIcr-0005eB-LX for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:33:09 -0500 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-216-C3XAVkpsMH28TZxDfOEKsQ-1; Thu, 11 Mar 2021 05:33:03 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 50A411015C8F for ; Thu, 11 Mar 2021 10:33:02 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id DEA4A5DF26; Thu, 11 Mar 2021 10:33:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615458785; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/99h6TfCR3pAsmKhZm5mKjTif2mO+t7aYAaYGvoa9JI=; b=HZwi9EcTc3x7kKW1ZxvSD3RmzASjFECksKYMMpoAnUjteKH0Sboq+AJShs8wANrkJOswsP fxARUkPfy4cuv0H0bdmHhgUgotVYhAwiOiErk4k32L5EqKVOeXyhwWIWqvCyEbJJTn2E1p wOKECvTQh1pT+Eal7P0UG0dsAFAHmpk= X-MC-Unique: C3XAVkpsMH28TZxDfOEKsQ-1 From: Paolo Bonzini To: qemu-devel@nongnu.org Subject: [PATCH 1/7] docs: vhost-user: clean up request/reply description Date: Thu, 11 Mar 2021 05:32:44 -0500 Message-Id: <20210311103250.532191-2-pbonzini@redhat.com> In-Reply-To: <20210311103250.532191-1-pbonzini@redhat.com> References: <20210311103250.532191-1-pbonzini@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pbonzini@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=63.128.21.124; envelope-from=pbonzini@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.243, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: marcandre.lureau@redhat.com, stefanha@redhat.com, mst@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) Content-Type: text/plain; charset="utf-8" It is not necessary to mention which side is sending/receiving each payload; it is more interesting to say which is the request and which is the reply. This also matches what vhost-user-gpu.rst already does. While at it, ensure that all messages list both the request and the reply payload. Signed-off-by: Paolo Bonzini Reviewed-by: Stefano Garzarella --- docs/interop/vhost-user.rst | 166 +++++++++++++++++++++--------------- 1 file changed, 98 insertions(+), 68 deletions(-) diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst index d6085f7045..4c46b16416 100644 --- a/docs/interop/vhost-user.rst +++ b/docs/interop/vhost-user.rst @@ -838,11 +838,14 @@ Protocol features Master message types -------------------- =20 +For this type of message, the request is sent by the master and the +reply is sent by the slave. + ``VHOST_USER_GET_FEATURES`` :id: 1 :equivalent ioctl: ``VHOST_GET_FEATURES`` - :master payload: N/A - :slave payload: ``u64`` + :request payload: N/A + :reply payload: ``u64`` =20 Get from the underlying vhost implementation the features bitmask. Feature bit ``VHOST_USER_F_PROTOCOL_FEATURES`` signals slave support @@ -852,7 +855,8 @@ Master message types ``VHOST_USER_SET_FEATURES`` :id: 2 :equivalent ioctl: ``VHOST_SET_FEATURES`` - :master payload: ``u64`` + :request payload: ``u64`` + :reply payload: N/A =20 Enable features in the underlying vhost implementation using a bitmask. Feature bit ``VHOST_USER_F_PROTOCOL_FEATURES`` signals @@ -862,8 +866,8 @@ Master message types ``VHOST_USER_GET_PROTOCOL_FEATURES`` :id: 15 :equivalent ioctl: ``VHOST_GET_FEATURES`` - :master payload: N/A - :slave payload: ``u64`` + :request payload: N/A + :reply payload: ``u64`` =20 Get the protocol feature bitmask from the underlying vhost implementation. Only legal if feature bit @@ -878,7 +882,8 @@ Master message types ``VHOST_USER_SET_PROTOCOL_FEATURES`` :id: 16 :equivalent ioctl: ``VHOST_SET_FEATURES`` - :master payload: ``u64`` + :request payload: ``u64`` + :reply payload: N/A =20 Enable protocol features in the underlying vhost implementation. =20 @@ -892,7 +897,8 @@ Master message types ``VHOST_USER_SET_OWNER`` :id: 3 :equivalent ioctl: ``VHOST_SET_OWNER`` - :master payload: N/A + :request payload: N/A + :reply payload: N/A =20 Issued when a new connection is established. It sets the current *master* as an owner of the session. This can be used on the *slave* @@ -900,7 +906,8 @@ Master message types =20 ``VHOST_USER_RESET_OWNER`` :id: 4 - :master payload: N/A + :request payload: N/A + :reply payload: N/A =20 .. admonition:: Deprecated =20 @@ -913,8 +920,8 @@ Master message types ``VHOST_USER_SET_MEM_TABLE`` :id: 5 :equivalent ioctl: ``VHOST_SET_MEM_TABLE`` - :master payload: memory regions description - :slave payload: (postcopy only) memory regions description + :request payload: memory regions description + :reply payload: (postcopy only) memory regions description =20 Sets the memory map regions on the slave so it can translate the vring addresses. In the ancillary data there is an array of file @@ -937,8 +944,8 @@ Master message types ``VHOST_USER_SET_LOG_BASE`` :id: 6 :equivalent ioctl: ``VHOST_SET_LOG_BASE`` - :master payload: u64 - :slave payload: N/A + :request payload: u64 + :reply payload: N/A =20 Sets logging shared memory space. =20 @@ -950,44 +957,48 @@ Master message types ``VHOST_USER_SET_LOG_FD`` :id: 7 :equivalent ioctl: ``VHOST_SET_LOG_FD`` - :master payload: N/A + :request payload: N/A + :reply payload: N/A =20 Sets the logging file descriptor, which is passed as ancillary data. =20 ``VHOST_USER_SET_VRING_NUM`` :id: 8 :equivalent ioctl: ``VHOST_SET_VRING_NUM`` - :master payload: vring state description + :request payload: vring state description + :reply payload: N/A =20 Set the size of the queue. =20 ``VHOST_USER_SET_VRING_ADDR`` :id: 9 :equivalent ioctl: ``VHOST_SET_VRING_ADDR`` - :master payload: vring address description - :slave payload: N/A + :request payload: vring address description + :reply payload: N/A =20 Sets the addresses of the different aspects of the vring. =20 ``VHOST_USER_SET_VRING_BASE`` :id: 10 :equivalent ioctl: ``VHOST_SET_VRING_BASE`` - :master payload: vring state description + :request payload: vring state description + :reply payload: N/A =20 Sets the base offset in the available vring. =20 ``VHOST_USER_GET_VRING_BASE`` :id: 11 :equivalent ioctl: ``VHOST_USER_GET_VRING_BASE`` - :master payload: vring state description - :slave payload: vring state description + :request payload: vring state description + :reply payload: vring state description =20 Get the available vring base offset. =20 ``VHOST_USER_SET_VRING_KICK`` :id: 12 :equivalent ioctl: ``VHOST_SET_VRING_KICK`` - :master payload: ``u64`` + :request payload: ``u64`` + :reply payload: N/A =20 Set the event file descriptor for adding buffers to the vring. It is passed in the ancillary data. @@ -1005,7 +1016,8 @@ Master message types ``VHOST_USER_SET_VRING_CALL`` :id: 13 :equivalent ioctl: ``VHOST_SET_VRING_CALL`` - :master payload: ``u64`` + :request payload: ``u64`` + :reply payload: N/A =20 Set the event file descriptor to signal when buffers are used. It is passed in the ancillary data. @@ -1023,7 +1035,8 @@ Master message types ``VHOST_USER_SET_VRING_ERR`` :id: 14 :equivalent ioctl: ``VHOST_SET_VRING_ERR`` - :master payload: ``u64`` + :request payload: ``u64`` + :reply payload: N/A =20 Set the event file descriptor to signal when error occurs. It is passed in the ancillary data. @@ -1040,8 +1053,8 @@ Master message types ``VHOST_USER_GET_QUEUE_NUM`` :id: 17 :equivalent ioctl: N/A - :master payload: N/A - :slave payload: u64 + :request payload: N/A + :reply payload: u64 =20 Query how many queues the backend supports. =20 @@ -1052,7 +1065,8 @@ Master message types ``VHOST_USER_SET_VRING_ENABLE`` :id: 18 :equivalent ioctl: N/A - :master payload: vring state description + :request payload: vring state description + :reply payload: N/A =20 Signal slave to enable or disable corresponding vring. =20 @@ -1062,7 +1076,8 @@ Master message types ``VHOST_USER_SEND_RARP`` :id: 19 :equivalent ioctl: N/A - :master payload: ``u64`` + :request payload: ``u64`` + :reply payload: N/A =20 Ask vhost user backend to broadcast a fake RARP to notify the migration is terminated for guest that does not support GUEST_ANNOUNCE. @@ -1077,7 +1092,8 @@ Master message types ``VHOST_USER_NET_SET_MTU`` :id: 20 :equivalent ioctl: N/A - :master payload: ``u64`` + :request payload: ``u64`` + :reply payload: N/A =20 Set host MTU value exposed to the guest. =20 @@ -1094,7 +1110,8 @@ Master message types ``VHOST_USER_SET_SLAVE_REQ_FD`` :id: 21 :equivalent ioctl: N/A - :master payload: N/A + :request payload: N/A + :reply payload: N/A =20 Set the socket file descriptor for slave initiated requests. It is passed in the ancillary data. @@ -1109,8 +1126,8 @@ Master message types ``VHOST_USER_IOTLB_MSG`` :id: 22 :equivalent ioctl: N/A (equivalent to ``VHOST_IOTLB_MSG`` message type) - :master payload: ``struct vhost_iotlb_msg`` - :slave payload: ``u64`` + :request payload: ``struct vhost_iotlb_msg`` + :reply payload: ``u64`` =20 Send IOTLB messages with ``struct vhost_iotlb_msg`` as payload. =20 @@ -1124,7 +1141,8 @@ Master message types ``VHOST_USER_SET_VRING_ENDIAN`` :id: 23 :equivalent ioctl: ``VHOST_SET_VRING_ENDIAN`` - :master payload: vring state description + :request payload: vring state description + :reply payload: N/A =20 Set the endianness of a VQ for legacy devices. Little-endian is indicated with state.num set to 0 and big-endian is indicated with @@ -1139,8 +1157,8 @@ Master message types ``VHOST_USER_GET_CONFIG`` :id: 24 :equivalent ioctl: N/A - :master payload: virtio device config space - :slave payload: virtio device config space + :request payload: virtio device config space + :reply payload: virtio device config space =20 When ``VHOST_USER_PROTOCOL_F_CONFIG`` is negotiated, this message is submitted by the vhost-user master to fetch the contents of the @@ -1153,8 +1171,8 @@ Master message types ``VHOST_USER_SET_CONFIG`` :id: 25 :equivalent ioctl: N/A - :master payload: virtio device config space - :slave payload: N/A + :request payload: virtio device config space + :reply payload: N/A =20 When ``VHOST_USER_PROTOCOL_F_CONFIG`` is negotiated, this message is submitted by the vhost-user master when the Guest changes the virtio @@ -1166,8 +1184,8 @@ Master message types ``VHOST_USER_CREATE_CRYPTO_SESSION`` :id: 26 :equivalent ioctl: N/A - :master payload: crypto session description - :slave payload: crypto session description + :request payload: crypto session description + :reply payload: crypto session description =20 Create a session for crypto operation. The server side must return the session id, 0 or positive for success, negative for failure. @@ -1179,7 +1197,8 @@ Master message types ``VHOST_USER_CLOSE_CRYPTO_SESSION`` :id: 27 :equivalent ioctl: N/A - :master payload: ``u64`` + :request payload: ``u64`` + :reply payload: N/A =20 Close a session for crypto operation which was previously created by ``VHOST_USER_CREATE_CRYPTO_SESSION``. @@ -1191,8 +1210,8 @@ Master message types =20 ``VHOST_USER_POSTCOPY_ADVISE`` :id: 28 - :master payload: N/A - :slave payload: userfault fd + :request payload: N/A + :reply payload: userfault fd =20 When ``VHOST_USER_PROTOCOL_F_PAGEFAULT`` is supported, the master advises slave that a migration with postcopy enabled is underway, @@ -1201,7 +1220,8 @@ Master message types =20 ``VHOST_USER_POSTCOPY_LISTEN`` :id: 29 - :master payload: N/A + :request payload: N/A + :reply payload: N/A =20 Master advises slave that a transition to postcopy mode has happened. The slave must ensure that shared memory is registered @@ -1212,10 +1232,11 @@ Master message types =20 ``VHOST_USER_POSTCOPY_END`` :id: 30 - :slave payload: ``u64`` + :request payload: N/A + :reply payload: ``u64`` =20 Master advises that postcopy migration has now completed. The slave - must disable the userfaultfd. The response is an acknowledgement + must disable the userfaultfd. The reply is an acknowledgement only. =20 When ``VHOST_USER_PROTOCOL_F_PAGEFAULT`` is supported, this message @@ -1227,7 +1248,8 @@ Master message types ``VHOST_USER_GET_INFLIGHT_FD`` :id: 31 :equivalent ioctl: N/A - :master payload: inflight description + :request payload: inflight description + :reply payload: N/A =20 When ``VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD`` protocol feature has been successfully negotiated, this message is submitted by master to @@ -1238,7 +1260,8 @@ Master message types ``VHOST_USER_SET_INFLIGHT_FD`` :id: 32 :equivalent ioctl: N/A - :master payload: inflight description + :request payload: inflight description + :reply payload: N/A =20 When ``VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD`` protocol feature has been successfully negotiated, this message is submitted by master to @@ -1248,7 +1271,8 @@ Master message types ``VHOST_USER_GPU_SET_SOCKET`` :id: 33 :equivalent ioctl: N/A - :master payload: N/A + :request payload: N/A + :reply payload: N/A =20 Sets the GPU protocol socket file descriptor, which is passed as ancillary data. The GPU protocol is used to inform the master of @@ -1257,8 +1281,8 @@ Master message types ``VHOST_USER_RESET_DEVICE`` :id: 34 :equivalent ioctl: N/A - :master payload: N/A - :slave payload: N/A + :request payload: N/A + :reply payload: N/A =20 Ask the vhost user backend to disable all rings and reset all internal device state to the initial state, ready to be @@ -1271,8 +1295,8 @@ Master message types ``VHOST_USER_VRING_KICK`` :id: 35 :equivalent ioctl: N/A - :slave payload: vring state description - :master payload: N/A + :request payload: vring state description + :reply payload: N/A =20 When the ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` protocol feature has been successfully negotiated, this message may be @@ -1285,7 +1309,8 @@ Master message types ``VHOST_USER_GET_MAX_MEM_SLOTS`` :id: 36 :equivalent ioctl: N/A - :slave payload: u64 + :request payload: N/A + :reply payload: u64 =20 When the ``VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS`` protocol feature has been successfully negotiated, this message is submitted @@ -1298,7 +1323,8 @@ Master message types ``VHOST_USER_ADD_MEM_REG`` :id: 37 :equivalent ioctl: N/A - :slave payload: single memory region description + :request payload: N/A + :reply payload: single memory region description =20 When the ``VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS`` protocol feature has been successfully negotiated, this message is submitted @@ -1313,7 +1339,8 @@ Master message types ``VHOST_USER_REM_MEM_REG`` :id: 38 :equivalent ioctl: N/A - :slave payload: single memory region description + :request payload: N/A + :reply payload: single memory region description =20 When the ``VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS`` protocol feature has been successfully negotiated, this message is submitted @@ -1328,8 +1355,8 @@ Master message types ``VHOST_USER_SET_STATUS`` :id: 39 :equivalent ioctl: VHOST_VDPA_SET_STATUS - :slave payload: N/A - :master payload: ``u64`` + :request payload: ``u64`` + :reply payload: N/A =20 When the ``VHOST_USER_PROTOCOL_F_STATUS`` protocol feature has been successfully negotiated, this message is submitted by the master to @@ -1339,8 +1366,8 @@ Master message types ``VHOST_USER_GET_STATUS`` :id: 40 :equivalent ioctl: VHOST_VDPA_GET_STATUS - :slave payload: ``u64`` - :master payload: N/A + :request payload: N/A + :reply payload: ``u64`` =20 When the ``VHOST_USER_PROTOCOL_F_STATUS`` protocol feature has been successfully negotiated, this message is submitted by the master to @@ -1351,11 +1378,14 @@ Master message types Slave message types ------------------- =20 +For this type of message, the request is sent by the slave and the reply +is sent by the master. + ``VHOST_USER_SLAVE_IOTLB_MSG`` :id: 1 :equivalent ioctl: N/A (equivalent to ``VHOST_IOTLB_MSG`` message type) - :slave payload: ``struct vhost_iotlb_msg`` - :master payload: N/A + :request payload: ``struct vhost_iotlb_msg`` + :reply payload: N/A =20 Send IOTLB messages with ``struct vhost_iotlb_msg`` as payload. Slave sends such requests to notify of an IOTLB miss, or an IOTLB @@ -1369,8 +1399,8 @@ Slave message types ``VHOST_USER_SLAVE_CONFIG_CHANGE_MSG`` :id: 2 :equivalent ioctl: N/A - :slave payload: N/A - :master payload: N/A + :request payload: N/A + :reply payload: N/A =20 When ``VHOST_USER_PROTOCOL_F_CONFIG`` is negotiated, vhost-user slave sends such messages to notify that the virtio device's @@ -1384,8 +1414,8 @@ Slave message types ``VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG`` :id: 3 :equivalent ioctl: N/A - :slave payload: vring area description - :master payload: N/A + :request payload: vring area description + :reply payload: N/A =20 Sets host notifier for a specified queue. The queue index is contained in the ``u64`` field of the vring area description. The @@ -1407,8 +1437,8 @@ Slave message types ``VHOST_USER_SLAVE_VRING_CALL`` :id: 4 :equivalent ioctl: N/A - :slave payload: vring state description - :master payload: N/A + :request payload: vring state description + :reply payload: N/A =20 When the ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` protocol feature has been successfully negotiated, this message may be @@ -1421,8 +1451,8 @@ Slave message types ``VHOST_USER_SLAVE_VRING_ERR`` :id: 5 :equivalent ioctl: N/A - :slave payload: vring state description - :master payload: N/A + :request payload: vring state description + :reply payload: N/A =20 When the ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` protocol feature has been successfully negotiated, this message may be @@ -1448,7 +1478,7 @@ client MUST respond with a Payload ``VhostUserMsg`` i= ndicating 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. =20 -The response payload gives QEMU a deterministic indication of the result +The reply payload gives QEMU a deterministic indication of the result of the command. 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. --=20 2.26.2 From nobody Fri May 17 06:54:20 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1615458869; cv=none; d=zohomail.com; s=zohoarc; b=lxCfPy/bwsvChJclzmPWTd8Kgw+OGdclI1vfq3UkMevvrBxOIZybyZCiZMxIKjrbGj85XuvOOY4fjFEaqTXekMWbd0tMA1rQ9k8tOiTxsmuNF5xfoJ/jb1rpFN1+TI5DZWRkgaEuSy1EiqtpRjwME/wNCXXwogxr0WX8Mw/S6uM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1615458869; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=3+2C00dicF9EURtOOEDG2FKDSOWKcew4Jt6KBqPzinU=; b=Ak3CcLfmOHm1q5ulhlsxjU1o5LlPxtPty0DoVtcI1GLwcEpTL0TI7v8l8PE3+YhqEDyXWatI+E0Z1qDYnml8GmiiE6hkHy2UKq1OBooYrJjk0tYDxcGcWDmk8SgeHMfEjHHraYC76f4TS2MPbrxFHIlyhhqKXjWFehTmWbLqpMc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1615458869420884.1832675160568; Thu, 11 Mar 2021 02:34:29 -0800 (PST) Received: from localhost ([::1]:39908 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKIeC-0004LT-6H for importer@patchew.org; Thu, 11 Mar 2021 05:34:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46848) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lKIcu-0002Xj-Rq for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:33:08 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:49660) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lKIcs-0005eI-7y for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:33:08 -0500 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-91-dC96cG8lPDKZs7C5lwnOAA-1; Thu, 11 Mar 2021 05:33:03 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CF5DB80159E for ; Thu, 11 Mar 2021 10:33:02 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6AE8B4EDBB; Thu, 11 Mar 2021 10:33:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615458785; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3+2C00dicF9EURtOOEDG2FKDSOWKcew4Jt6KBqPzinU=; b=E4dOc/fj+XJZqMN6aobbGl8AyQ45siFK7kZ7HaCGEq3Xvocp9H0ELjM5Ot5F3TlSYAcdX1 I0NMdQ2RASa0MxsIZSpzP+DwwE3NEn4Ndzuydajn8SNkm2qCW8ivzcmzPRSQ8Ijof2GrwS JrqGtbGSLo+PY42W6RnWuM+XgShdf24= X-MC-Unique: dC96cG8lPDKZs7C5lwnOAA-1 From: Paolo Bonzini To: qemu-devel@nongnu.org Subject: [PATCH 2/7] docs: vhost-user: rewrite section on ring state machine Date: Thu, 11 Mar 2021 05:32:45 -0500 Message-Id: <20210311103250.532191-3-pbonzini@redhat.com> In-Reply-To: <20210311103250.532191-1-pbonzini@redhat.com> References: <20210311103250.532191-1-pbonzini@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pbonzini@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=216.205.24.124; envelope-from=pbonzini@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.243, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: marcandre.lureau@redhat.com, stefanha@redhat.com, mst@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) Content-Type: text/plain; charset="utf-8" This section is using the word "back-end" to refer to the "slave's back-end", and talking about the "client" for what the rest of the document calls the "slave". Rework it to free the use of the term "back-end", which in the next patch will replace "slave". Signed-off-by: Paolo Bonzini Reviewed-by: Stefano Garzarella --- v1->v2: adjust wording according to review docs/interop/vhost-user.rst | 46 +++++++++++++++++-------------------- 1 file changed, 21 insertions(+), 25 deletions(-) diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst index 4c46b16416..f98896fbd0 100644 --- a/docs/interop/vhost-user.rst +++ b/docs/interop/vhost-user.rst @@ -307,40 +307,36 @@ bit was dedicated for this purpose:: =20 #define VHOST_USER_F_PROTOCOL_FEATURES 30 =20 -Starting and stopping rings ---------------------------- +Ring states +----------- =20 -Client must only process each ring when it is started. +Rings can be in one of three states: =20 -Client must only pass data between the ring and the backend, when the -ring is enabled. +* stopped: the slave must not process the ring at all. =20 -If ring is started but disabled, client must process the ring without -talking to the backend. +* started but disabled: the slave must process the ring without + causing any side effects. For example, for a networking device, + in the disabled state the slave must not supply any new RX packets, + but must process and discard any TX packets. =20 -For example, for a networking device, in the disabled state client -must not supply any new RX packets, but must process and discard any -TX packets. +* started and enabled. =20 -If ``VHOST_USER_F_PROTOCOL_FEATURES`` has not been negotiated, the -ring is initialized in an enabled state. +Each ring is initialized in a stopped state. The slave must start the +ring upon receiving a kick (that is, detecting that file descriptor is +readable) on the descriptor specified by ``VHOST_USER_SET_VRING_KICK``, +or receiving the in-band message ``VHOST_USER_VRING_KICK`` if negotiated. +The slave must stop the ring upon receiving ``VHOST_USER_GET_VRING_BASE``. =20 -If ``VHOST_USER_F_PROTOCOL_FEATURES`` has been negotiated, the ring is -initialized in a disabled state. Client must not pass data to/from the -backend until ring is enabled by ``VHOST_USER_SET_VRING_ENABLE`` with -parameter 1, or after it has been disabled by -``VHOST_USER_SET_VRING_ENABLE`` with parameter 0. +Rings can be enabled or disabled by ``VHOST_USER_SET_VRING_ENABLE``. =20 -Each ring is initialized in a stopped state, client must not process -it until ring is started, or after it has been stopped. +If ``VHOST_USER_F_PROTOCOL_FEATURES`` has not been negotiated, the +ring is initialized in the stopped but enabled state. =20 -Client must start ring upon receiving a kick (that is, detecting that -file descriptor is readable) on the descriptor specified by -``VHOST_USER_SET_VRING_KICK`` or receiving the in-band message -``VHOST_USER_VRING_KICK`` if negotiated, and stop ring upon receiving -``VHOST_USER_GET_VRING_BASE``. +If ``VHOST_USER_F_PROTOCOL_FEATURES`` has been negotiated, the ring is +initialized in a disabled state and is enabled by +``VHOST_USER_SET_VRING_ENABLE`` with parameter 1. =20 -While processing the rings (whether they are enabled or not), client +While processing the rings (whether they are enabled or not), the slave must support changing some configuration aspects on the fly. =20 Multiple queue support --=20 2.26.2 From nobody Fri May 17 06:54:20 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1615459032; cv=none; d=zohomail.com; s=zohoarc; b=VSxFjXybH6c5W+jQ2vFzfz52X01ydbiAgB9c6+Yn0IQxGljRbMUEfzFv9Kkb2Bq+PNZveL/N5Km4LF6F6YP3WhhthsG27ZWygxH5b05OW9EEf2V6EZ4uB1QEMqA9INmo3e5zqi3OgCgA/qM5wytCNUyMYl5eMyolxxb/++HklzU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1615459032; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=LLcFNkqOkaJ8qyUL1RxviiUPLzvjpxNQr4n6RcWbZH4=; b=EOR/dwM9fMlBhD/h9EJX4gipQozz6oZW9jAkCObqfL3fKPv83YC2uOD5V/11u+wIw/cbxqrAHmrDBRC4IfCFcpXSo7YVPOInbXdg4gtBDOTZ6d9k8Y/JxjX71xJshlCzTrAHYhz+Gs6bD+1P6zcCTxsGig9ueFdn73vrTNitdQQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 16154590326381023.1620029756409; Thu, 11 Mar 2021 02:37:12 -0800 (PST) Received: from localhost ([::1]:50898 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKIgp-0000oe-HF for importer@patchew.org; Thu, 11 Mar 2021 05:37:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46894) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lKIcx-0002cB-Jl for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:33:11 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:52898) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lKIcs-0005ec-S4 for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:33:11 -0500 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-524-YtDVkFNIMgyGVLwj1zH2WQ-1; Thu, 11 Mar 2021 05:33:04 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5D52610866A3 for ; Thu, 11 Mar 2021 10:33:03 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id EB1B529400; Thu, 11 Mar 2021 10:33:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615458786; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LLcFNkqOkaJ8qyUL1RxviiUPLzvjpxNQr4n6RcWbZH4=; b=ZXVfx9fo7yet1iIGktxsZUkkHRpsfVEDV5dx/b15PFLFu6vLkjATP9oDt3tpfoQaOMEeUW jWPPFS7sOIPwkHv1ZuO0amMvwHFlMYFz4TD+CoSuHhgT3e6TLE2yPUyi4hEwvfmDR/jyb9 jZw11QNcHVujdYI777wghGHECb/nUMs= X-MC-Unique: YtDVkFNIMgyGVLwj1zH2WQ-1 From: Paolo Bonzini To: qemu-devel@nongnu.org Subject: [PATCH 3/7] docs: vhost-user: replace master/slave with frontend/backend Date: Thu, 11 Mar 2021 05:32:46 -0500 Message-Id: <20210311103250.532191-4-pbonzini@redhat.com> In-Reply-To: <20210311103250.532191-1-pbonzini@redhat.com> References: <20210311103250.532191-1-pbonzini@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pbonzini@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=63.128.21.124; envelope-from=pbonzini@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.243, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: marcandre.lureau@redhat.com, stefanha@redhat.com, mst@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) Content-Type: text/plain; charset="utf-8" This matches the nomenclature that is generally used. Also commonly used is client/server, but it is not as clear because sometimes the frontend exposes a passive (server) socket that the backend connects to. Signed-off-by: Paolo Bonzini Reviewed-by: Stefano Garzarella --- v1->v2: use frontend/backend instead of the version with hyphen docs/interop/vhost-user-gpu.rst | 10 +- docs/interop/vhost-user.rst | 302 ++++++++++++++++---------------- 2 files changed, 156 insertions(+), 156 deletions(-) diff --git a/docs/interop/vhost-user-gpu.rst b/docs/interop/vhost-user-gpu.= rst index 3268bf405c..1926149c07 100644 --- a/docs/interop/vhost-user-gpu.rst +++ b/docs/interop/vhost-user-gpu.rst @@ -12,10 +12,10 @@ Introduction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 The vhost-user-gpu protocol is aiming at sharing the rendering result -of a virtio-gpu, done from a vhost-user slave process to a vhost-user -master process (such as QEMU). It bears a resemblance to a display +of a virtio-gpu, done from a vhost-user backend process to a vhost-user +frontend process (such as QEMU). It bears a resemblance to a display server protocol, if you consider QEMU as the display server and the -slave as the client, but in a very limited way. Typically, it will +backend as the client, but in a very limited way. Typically, it will work by setting a scanout/display configuration, before sending flush events for the display updates. It will also update the cursor shape and position. @@ -25,8 +25,8 @@ socket ancillary data to share opened file descriptors (D= MABUF fds or shared memory). The socket is usually obtained via ``VHOST_USER_GPU_SET_SOCKET``. =20 -Requests are sent by the *slave*, and the optional replies by the -*master*. +Requests are sent by the *backend*, and the optional replies by the +*frontend*. =20 Wire format =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst index f98896fbd0..96be549127 100644 --- a/docs/interop/vhost-user.rst +++ b/docs/interop/vhost-user.rst @@ -19,19 +19,19 @@ space process on the same host. It uses communication o= ver a Unix domain socket to share file descriptors in the ancillary data of the message. =20 -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. +The protocol defines 2 sides of the communication, *frontend* and +*backend*. The *frontend* is the application that shares its virtqueues, in +our case QEMU. The *backend* is the consumer of the virtqueues. =20 -In the current implementation QEMU is the *master*, and the *slave* is -the external process consuming the virtio queues, for example a +In the current implementation QEMU is the *frontend*, and the *backend* +is the external process consuming the virtio queues, for example a software Ethernet switch running in user space, such as Snabbswitch, or a block device backend processing read & write to a virtual disk. In order to facilitate interoperability between various backend implementations, it is recommended to follow the :ref:`Backend program conventions `. =20 -*Master* and *slave* can be either a client (i.e. connecting) or +The *frontend* and *backend* can be either a client (i.e. connecting) or server (listening) in the socket communication. =20 Message Specification @@ -53,7 +53,7 @@ Header :flags: 32-bit bit field =20 - 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 from the backend - Bit 3 is the need_reply flag - see :ref:`REPLY_ACK ` for details. =20 @@ -198,8 +198,8 @@ Virtio device config space :size: a 32-bit configuration space access size in bytes =20 :flags: a 32-bit value: - - 0: Vhost master messages used for writeable fields - - 1: Vhost master messages used for live migration + - 0: Vhost frontend messages used for writeable fields + - 1: Vhost frontend messages used for live migration =20 :payload: Size bytes array holding the contents of the virtio device's configuration space @@ -266,8 +266,8 @@ vhost for the Linux Kernel. Most messages that can be s= ent via the Unix domain socket implementing vhost-user have an equivalent ioctl to the kernel implementation. =20 -The communication consists of *master* sending message requests and -*slave* sending message replies. Most of the requests don't require +The communication consists of the *frontend* sending message requests and +the *backend* sending message replies. Most of the requests don't require replies. Here is a list of the ones that do: =20 * ``VHOST_USER_GET_FEATURES`` @@ -281,7 +281,7 @@ replies. Here is a list of the ones that do: :ref:`REPLY_ACK ` The section on ``REPLY_ACK`` protocol extension. =20 -There are several messages that the master sends with file descriptors pas= sed +There are several messages that the frontend sends with file descriptors p= assed in the ancillary data: =20 * ``VHOST_USER_SET_MEM_TABLE`` @@ -293,16 +293,16 @@ in the ancillary data: * ``VHOST_USER_SET_SLAVE_REQ_FD`` * ``VHOST_USER_SET_INFLIGHT_FD`` (if ``VHOST_USER_PROTOCOL_F_INFLIGHT_SHMF= D``) =20 -If *master* is unable to send the full message or receives a wrong +If *frontend* is unable to send the full message or receives a wrong reply it will close the connection. An optional reconnection mechanism can be implemented. =20 -If *slave* detects some error such as incompatible features, it may also +If *backend* detects some error such as incompatible features, it may also close the connection. This should only happen in exceptional circumstances. =20 Any protocol extensions are gated by protocol feature bits, which -allows full backwards compatibility on both master and slave. As -older slaves don't support negotiating protocol features, a feature +allows full backwards compatibility on both frontend and backend. As +older backends don't support negotiating protocol features, a feature bit was dedicated for this purpose:: =20 #define VHOST_USER_F_PROTOCOL_FEATURES 30 @@ -312,20 +312,20 @@ Ring states =20 Rings can be in one of three states: =20 -* stopped: the slave must not process the ring at all. +* stopped: the backend must not process the ring at all. =20 -* started but disabled: the slave must process the ring without +* started but disabled: the backend must process the ring without causing any side effects. For example, for a networking device, - in the disabled state the slave must not supply any new RX packets, + in the disabled state the backend must not supply any new RX packets, but must process and discard any TX packets. =20 * started and enabled. =20 -Each ring is initialized in a stopped state. The slave must start the +Each ring is initialized in a stopped state. The backend must start the ring upon receiving a kick (that is, detecting that file descriptor is readable) on the descriptor specified by ``VHOST_USER_SET_VRING_KICK``, or receiving the in-band message ``VHOST_USER_VRING_KICK`` if negotiated. -The slave must stop the ring upon receiving ``VHOST_USER_GET_VRING_BASE``. +The backend must stop the ring upon receiving ``VHOST_USER_GET_VRING_BASE`= `. =20 Rings can be enabled or disabled by ``VHOST_USER_SET_VRING_ENABLE``. =20 @@ -336,53 +336,53 @@ If ``VHOST_USER_F_PROTOCOL_FEATURES`` has been negoti= ated, the ring is initialized in a disabled state and is enabled by ``VHOST_USER_SET_VRING_ENABLE`` with parameter 1. =20 -While processing the rings (whether they are enabled or not), the slave +While processing the rings (whether they are enabled or not), the backend must support changing some configuration aspects on the fly. =20 Multiple queue support ---------------------- =20 -Many devices have a fixed number of virtqueues. In this case the master +Many devices have a fixed number of virtqueues. In this case the frontend already knows the number of available virtqueues without communicating wit= h the -slave. +backend. =20 Some devices do not have a fixed number of virtqueues. Instead the maximum -number of virtqueues is chosen by the slave. The number can depend on host -resource availability or slave implementation details. Such devices are c= alled +number of virtqueues is chosen by the backend. The number can depend on h= ost +resource availability or backend implementation details. Such devices are= called multiple queue devices. =20 -Multiple queue support allows the slave to advertise the maximum number of -queues. This is treated as a protocol extension, hence the slave has to +Multiple queue support allows the backend to advertise the maximum number = of +queues. This is treated as a protocol extension, hence the backend has to implement protocol features first. The multiple queues feature is supported only when the protocol feature ``VHOST_USER_PROTOCOL_F_MQ`` (bit 0) is set. =20 -The max number of queues the slave supports can be queried with message -``VHOST_USER_GET_QUEUE_NUM``. Master should stop when the number of reques= ted +The max number of queues the backend supports can be queried with message +``VHOST_USER_GET_QUEUE_NUM``. Frontend should stop when the number of requ= ested queues is bigger than that. =20 -As all queues share one connection, the master uses a unique index for each +As all queues share one connection, the frontend uses a unique index for e= ach queue in the sent message to identify a specified queue. =20 -The master enables queues by sending message ``VHOST_USER_SET_VRING_ENABLE= ``. +The frontend enables queues by sending message ``VHOST_USER_SET_VRING_ENAB= LE``. vhost-user-net has historically automatically enabled the first queue pair. =20 -Slaves should always implement the ``VHOST_USER_PROTOCOL_F_MQ`` protocol +Back-ends should always implement the ``VHOST_USER_PROTOCOL_F_MQ`` protocol feature, even for devices with a fixed number of virtqueues, since it is s= imple to implement and offers a degree of introspection. =20 -Masters must not rely on the ``VHOST_USER_PROTOCOL_F_MQ`` protocol feature= for +Frontends must not rely on the ``VHOST_USER_PROTOCOL_F_MQ`` protocol featu= re for devices with a fixed number of virtqueues. Only true multiqueue devices require this protocol feature. =20 Migration --------- =20 -During live migration, the master may need to track the modifications -the slave makes to the memory mapped regions. The client should mark +During live migration, the frontend may need to track the modifications +the backend makes to the memory mapped regions. The frontend should mark the dirty pages in a log. Once it complies to this logging, it may declare the ``VHOST_F_LOG_ALL`` vhost feature. =20 -To start/stop logging of data/used ring writes, server may send +To start/stop logging of data/used ring writes, the frontend may send messages ``VHOST_USER_SET_FEATURES`` with ``VHOST_F_LOG_ALL`` and ``VHOST_USER_SET_VRING_ADDR`` with ``VHOST_VRING_F_LOG`` in ring's flags set to 1/0, respectively. @@ -396,7 +396,7 @@ Dirty pages are of size:: #define VHOST_LOG_PAGE 0x1000 =20 The log memory fd is provided in the ancillary data of -``VHOST_USER_SET_LOG_BASE`` message when the slave has +``VHOST_USER_SET_LOG_BASE`` message when the backend has ``VHOST_USER_PROTOCOL_F_LOG_SHMFD`` protocol feature. =20 The size of the log is supplied as part of ``VhostUserMsg`` which @@ -422,26 +422,26 @@ the bit offset of the last byte of the ring must fall= within the size supplied by ``VhostUserLog``. =20 ``VHOST_USER_SET_LOG_FD`` is an optional message with an eventfd in -ancillary data, it may be used to inform the master that the log has +ancillary data, it may be used to inform the frontend that the log has been modified. =20 Once the source has finished migration, rings will be stopped by the source. No further update must be done before rings are restarted. =20 -In postcopy migration the slave is started before all the memory has +In postcopy migration the backend is started before all the memory has been received from the source host, and care must be taken to avoid -accessing pages that have yet to be received. The slave opens a +accessing pages that have yet to be received. The backend opens a 'userfault'-fd and registers the memory with it; this fd is then -passed back over to the master. The master services requests on the +passed back over to the frontend. The frontend services requests on the userfaultfd for pages that are accessed and when the page is available it performs WAKE ioctl's on the userfaultfd to wake the stalled -slave. The client indicates support for this via the +backend. The frontend indicates support for this via the ``VHOST_USER_PROTOCOL_F_PAGEFAULT`` feature. =20 Memory access ------------- =20 -The master sends a list of vhost memory regions to the slave using the +The frontend sends a list of vhost memory regions to the backend using the ``VHOST_USER_SET_MEM_TABLE`` message. Each region has two base addresses: a guest address and a user address. =20 @@ -466,60 +466,60 @@ IOMMU support ------------- =20 When the ``VIRTIO_F_IOMMU_PLATFORM`` feature has been negotiated, the -master sends IOTLB entries update & invalidation by sending -``VHOST_USER_IOTLB_MSG`` requests to the slave with a ``struct +frontend sends IOTLB entries update & invalidation by sending +``VHOST_USER_IOTLB_MSG`` requests to the backend with a ``struct vhost_iotlb_msg`` as payload. For update events, the ``iotlb`` payload has to be filled with the update message type (2), the I/O virtual address, the size, the user virtual address, and the permissions flags. Addresses and size must be within vhost memory regions set via the ``VHOST_USER_SET_MEM_TABLE`` request. For invalidation events, the ``iotlb`` payload has to be filled with the invalidation message type -(3), the I/O virtual address and the size. On success, the slave is +(3), the I/O virtual address and the size. On success, the backend is expected to reply with a zero payload, non-zero otherwise. =20 -The slave relies on the slave communication channel (see :ref:`Slave -communication ` section below) to send IOTLB miss +The backend relies on the backend communication channel (see :ref:`Back-end +communication ` section below) to send IOTLB miss and access failure events, by sending ``VHOST_USER_SLAVE_IOTLB_MSG`` -requests to the master with a ``struct vhost_iotlb_msg`` as +requests to the frontend with a ``struct vhost_iotlb_msg`` as payload. For miss events, the iotlb payload has to be filled with the miss message type (1), the I/O virtual address and the permissions flags. For access failure event, the iotlb payload has to be filled with the access failure message type (4), the I/O virtual address and -the permissions flags. For synchronization purpose, the slave may -rely on the reply-ack feature, so the master may send a reply when +the permissions flags. For synchronization purpose, the backend may +rely on the reply-ack feature, so the frontend may send a reply when operation is completed if the reply-ack feature is negotiated and -slaves requests a reply. For miss events, completed operation means -either master sent an update message containing the IOTLB entry -containing requested address and permission, or master sent nothing if +backends requests a reply. For miss events, completed operation means +either frontend sent an update message containing the IOTLB entry +containing requested address and permission, or frontend sent nothing if the IOTLB miss message is invalid (invalid IOVA or permission). =20 -The master isn't expected to take the initiative to send IOTLB update -messages, as the slave sends IOTLB miss messages for the guest virtual +The frontend isn't expected to take the initiative to send IOTLB update +messages, as the backend sends IOTLB miss messages for the guest virtual memory areas it needs to access. =20 -.. _slave_communication: +.. _backend_communication: =20 -Slave communication -------------------- +Back-end communication +---------------------- =20 -An optional communication channel is provided if the slave declares +An optional communication channel is provided if the backend declares ``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` protocol feature, to allow the -slave to make requests to the master. +backend to make requests to the frontend. =20 The fd is provided via ``VHOST_USER_SET_SLAVE_REQ_FD`` ancillary data. =20 -A slave may then send ``VHOST_USER_SLAVE_*`` messages to the master +A backend may then send ``VHOST_USER_SLAVE_*`` messages to the frontend using this fd communication channel. =20 If ``VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD`` protocol feature is -negotiated, slave can send file descriptors (at most 8 descriptors in -each message) to master via ancillary data using this fd communication +negotiated, backend can send file descriptors (at most 8 descriptors in +each message) to frontend via ancillary data using this fd communication channel. =20 Inflight I/O tracking --------------------- =20 -To support reconnecting after restart or crash, slave may need to +To support reconnecting after restart or crash, backend may need to resubmit inflight I/Os. If virtqueue is processed in order, we can easily achieve that by getting the inflight descriptors from descriptor table (split virtqueue) or descriptor ring (packed @@ -527,18 +527,18 @@ virtqueue). However, it can't work when we process de= scriptors out-of-order because some entries which store the information of inflight descriptors in available ring (split virtqueue) or descriptor ring (packed virtqueue) might be overridden by new entries. To solve -this problem, slave need to allocate an extra buffer to store this -information of inflight descriptors and share it with master for +this problem, the backend need to allocate an extra buffer to store this +information of inflight descriptors and share it with frontend for persistent. ``VHOST_USER_GET_INFLIGHT_FD`` and ``VHOST_USER_SET_INFLIGHT_FD`` are used to transfer this buffer -between master and slave. And the format of this buffer is described +between frontend and backend. And the format of this buffer is described below: =20 +---------------+---------------+-----+---------------+ | queue0 region | queue1 region | ... | queueN region | +---------------+---------------+-----+---------------+ =20 -N is the number of available virtqueues. Slave could get it from num +N is the number of available virtqueues. The backend could get it from num queues field of ``VhostUserInflight``. =20 For split virtqueue, queue region can be implemented as: @@ -570,8 +570,8 @@ For split virtqueue, queue region can be implemented as: * Zero value indicates an uninitialized buffer */ uint16_t version; =20 - /* The size of DescStateSplit array. It's equal to the virtqueue - * size. Slave could get it from queue size field of VhostUserInflig= ht. */ + /* The size of DescStateSplit array. It's equal to the virtqueue siz= e. + * The backend could get it from queue size field of VhostUserInflig= ht. */ uint16_t desc_num; =20 /* The head of list that track the last batch of used descriptors. */ @@ -677,8 +677,8 @@ For packed virtqueue, queue region can be implemented a= s: * Zero value indicates an uninitialized buffer */ uint16_t version; =20 - /* The size of DescStatePacked array. It's equal to the virtqueue - * size. Slave could get it from queue size field of VhostUserInflig= ht. */ + /* The size of DescStatePacked array. It's equal to the virtqueue si= ze. + * The backend could get it from queue size field of VhostUserInflig= ht. */ uint16_t desc_num; =20 /* The head of free DescStatePacked entry list */ @@ -770,7 +770,7 @@ When reconnecting: #. Use ``old_used_wrap_counter`` to calculate the available flags =20 #. If ``d.flags`` is not equal to the calculated flags value (means - slave has submitted the buffer to guest driver before crash, so + backend has submitted the buffer to guest driver before crash, so it has to commit the in-progres update), set ``old_free_head``, ``old_used_idx``, ``old_used_wrap_counter`` to ``free_head``, ``used_idx``, ``used_wrap_counter`` @@ -799,11 +799,11 @@ cause the sending application(s) to block, it is not = advised to use this feature unless absolutely necessary. It is also considered an error to negotiate this feature without also negotiating ``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` and ``VHOST_USER_PROTOCOL_F_REPLY_ACK`= `, -the former is necessary for getting a message channel from the slave -to the master, while the latter needs to be used with the in-band +the former is necessary for getting a message channel from the backend +to the frontend, while the latter needs to be used with the in-band notification messages to block until they are processed, both to avoid blocking later and for proper processing (at least in the simulation -use case.) As it has no other way of signalling this error, the slave +use case.) As it has no other way of signalling this error, the backend should close the connection as a response to a ``VHOST_USER_SET_PROTOCOL_FEATURES`` message that sets the in-band notifications feature flag without the other two. @@ -831,11 +831,11 @@ Protocol features #define VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS 15 #define VHOST_USER_PROTOCOL_F_STATUS 16 =20 -Master message types --------------------- +Frontend message types +----------------------- =20 -For this type of message, the request is sent by the master and the -reply is sent by the slave. +For this type of message, the request is sent by the frontend and the +reply is sent by the backend. =20 ``VHOST_USER_GET_FEATURES`` :id: 1 @@ -844,7 +844,7 @@ reply is sent by the slave. :reply payload: ``u64`` =20 Get from the underlying vhost implementation the features bitmask. - Feature bit ``VHOST_USER_F_PROTOCOL_FEATURES`` signals slave support + Feature bit ``VHOST_USER_F_PROTOCOL_FEATURES`` signals backend support for ``VHOST_USER_GET_PROTOCOL_FEATURES`` and ``VHOST_USER_SET_PROTOCOL_FEATURES``. =20 @@ -856,7 +856,7 @@ reply is sent by the slave. =20 Enable features in the underlying vhost implementation using a bitmask. Feature bit ``VHOST_USER_F_PROTOCOL_FEATURES`` signals - slave support for ``VHOST_USER_GET_PROTOCOL_FEATURES`` and + backend support for ``VHOST_USER_GET_PROTOCOL_FEATURES`` and ``VHOST_USER_SET_PROTOCOL_FEATURES``. =20 ``VHOST_USER_GET_PROTOCOL_FEATURES`` @@ -871,7 +871,7 @@ reply is sent by the slave. ``VHOST_USER_GET_FEATURES``. =20 .. Note:: - Slave that reported ``VHOST_USER_F_PROTOCOL_FEATURES`` must + Back-ends that report ``VHOST_USER_F_PROTOCOL_FEATURES`` must support this message even before ``VHOST_USER_SET_FEATURES`` was called. =20 @@ -887,7 +887,7 @@ reply is sent by the slave. ``VHOST_USER_GET_FEATURES``. =20 .. Note:: - Slave that reported ``VHOST_USER_F_PROTOCOL_FEATURES`` must support + Back-ends that report ``VHOST_USER_F_PROTOCOL_FEATURES`` must support this message even before ``VHOST_USER_SET_FEATURES`` was called. =20 ``VHOST_USER_SET_OWNER`` @@ -896,8 +896,8 @@ reply is sent by the slave. :request payload: N/A :reply payload: N/A =20 - Issued when a new connection is established. It sets the current - *master* as an owner of the session. This can be used on the *slave* + Issued when a new connection is established. It marks the sender + as the frontend that owns of the session. This can be used on the *backe= nd* as a "session start" flag. =20 ``VHOST_USER_RESET_OWNER`` @@ -908,9 +908,9 @@ reply is sent by the slave. .. admonition:: Deprecated =20 This is no longer used. Used to be sent to request disabling all - rings, but some clients interpreted it to also discard connection + rings, but some backends interpreted it to also discard connection state (this interpretation would lead to bugs). It is recommended - that clients either ignore this message, or use it to disable all + that backends either ignore this message, or use it to disable all rings. =20 ``VHOST_USER_SET_MEM_TABLE`` @@ -919,14 +919,14 @@ reply is sent by the slave. :request payload: memory regions description :reply payload: (postcopy only) memory regions description =20 - Sets the memory map regions on the slave so it can translate the + Sets the memory map regions on the backend so it can translate the vring addresses. In the ancillary data there is an array of file descriptors for each memory mapped region. The size and ordering of the fds matches the number and ordering of memory regions. =20 When ``VHOST_USER_POSTCOPY_LISTEN`` has been received, ``SET_MEM_TABLE`` replies with the bases of the memory mapped - regions to the master. The slave must have mmap'd the regions but + regions to the frontend. The backend must have mmap'd the regions but not yet accessed them and should not yet generate a userfault event. =20 @@ -945,7 +945,7 @@ reply is sent by the slave. =20 Sets logging shared memory space. =20 - When slave has ``VHOST_USER_PROTOCOL_F_LOG_SHMFD`` protocol feature, + When the backend has ``VHOST_USER_PROTOCOL_F_LOG_SHMFD`` protocol featur= e, the log memory fd is provided in the ancillary data of ``VHOST_USER_SET_LOG_BASE`` message, the size and offset of shared memory area provided in the message. @@ -1064,7 +1064,7 @@ reply is sent by the slave. :request payload: vring state description :reply payload: N/A =20 - Signal slave to enable or disable corresponding vring. + Signal the backend to enable or disable corresponding vring. =20 This request should be sent only when ``VHOST_USER_F_PROTOCOL_FEATURES`` has been negotiated. @@ -1099,7 +1099,7 @@ reply is sent by the slave. ``VHOST_USER_PROTOCOL_F_NET_MTU`` is present in ``VHOST_USER_GET_PROTOCOL_FEATURES``. =20 - If ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, slave must + If ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, the backend must respond with zero in case the specified MTU is valid, or non-zero otherwise. =20 @@ -1109,14 +1109,14 @@ reply is sent by the slave. :request payload: N/A :reply payload: N/A =20 - Set the socket file descriptor for slave initiated requests. It is passed + Set the socket file descriptor for backend initiated requests. It is pas= sed in the ancillary data. =20 This request should be sent only when ``VHOST_USER_F_PROTOCOL_FEATURES`` has been negotiated, and protocol feature bit ``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` bit is present in ``VHOST_USER_GET_PROTOCOL_FEATURES``. If - ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, slave must + ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, the backend must respond with zero for success, non-zero otherwise. =20 ``VHOST_USER_IOTLB_MSG`` @@ -1127,8 +1127,8 @@ reply is sent by the slave. =20 Send IOTLB messages with ``struct vhost_iotlb_msg`` as payload. =20 - Master sends such requests to update and invalidate entries in the - device IOTLB. The slave has to acknowledge the request with sending + The frontend sends such requests to update and invalidate entries in the + device IOTLB. The backend has to acknowledge the request with sending zero as ``u64`` payload for success, non-zero otherwise. =20 This request should be send only when ``VIRTIO_F_IOMMU_PLATFORM`` @@ -1148,7 +1148,7 @@ reply is sent by the slave. ``VHOST_USER_PROTOCOL_F_CROSS_ENDIAN`` has been negotiated. Backends that negotiated this feature should handle both endiannesses and expect this message once (per VQ) during device - configuration (ie. before the master starts the VQ). + configuration (ie. before the frontend starts the VQ). =20 ``VHOST_USER_GET_CONFIG`` :id: 24 @@ -1157,11 +1157,11 @@ reply is sent by the slave. :reply payload: virtio device config space =20 When ``VHOST_USER_PROTOCOL_F_CONFIG`` is negotiated, this message is - submitted by the vhost-user master to fetch the contents of the - virtio device configuration space, vhost-user slave's payload size - MUST match master's request, vhost-user slave uses zero length of - payload to indicate an error to vhost-user master. The vhost-user - master may cache the contents to avoid repeated + submitted by the vhost-user frontend to fetch the contents of the + virtio device configuration space, vhost-user backend's payload size + MUST match the frontend's request, vhost-user backend uses zero length of + payload to indicate an error to the vhost-user frontend. The vhost-user + frontend may cache the contents to avoid repeated ``VHOST_USER_GET_CONFIG`` calls. =20 ``VHOST_USER_SET_CONFIG`` @@ -1171,10 +1171,10 @@ reply is sent by the slave. :reply payload: N/A =20 When ``VHOST_USER_PROTOCOL_F_CONFIG`` is negotiated, this message is - submitted by the vhost-user master when the Guest changes the virtio + submitted by the vhost-user frontend when the Guest changes the virtio device configuration space and also can be used for live migration - on the destination host. The vhost-user slave must check the flags - field, and slaves MUST NOT accept SET_CONFIG for read-only + on the destination host. The vhost-user backend must check the flags + field, and backends MUST NOT accept SET_CONFIG for read-only configuration space fields unless the live migration bit is set. =20 ``VHOST_USER_CREATE_CRYPTO_SESSION`` @@ -1183,7 +1183,7 @@ reply is sent by the slave. :request payload: crypto session description :reply payload: crypto session description =20 - Create a session for crypto operation. The server side must return + Create a session for crypto operation. The backend must return the session id, 0 or positive for success, negative for failure. This request should be sent only when ``VHOST_USER_PROTOCOL_F_CRYPTO_SESSION`` feature has been @@ -1209,9 +1209,9 @@ reply is sent by the slave. :request payload: N/A :reply payload: userfault fd =20 - When ``VHOST_USER_PROTOCOL_F_PAGEFAULT`` is supported, the master - advises slave that a migration with postcopy enabled is underway, - the slave must open a userfaultfd for later use. Note that at this + When ``VHOST_USER_PROTOCOL_F_PAGEFAULT`` is supported, the frontend + advises backend that a migration with postcopy enabled is underway, + the backend must open a userfaultfd for later use. Note that at this stage the migration is still in precopy mode. =20 ``VHOST_USER_POSTCOPY_LISTEN`` @@ -1219,8 +1219,8 @@ reply is sent by the slave. :request payload: N/A :reply payload: N/A =20 - Master advises slave that a transition to postcopy mode has - happened. The slave must ensure that shared memory is registered + The frontend advises backend that a transition to postcopy mode has + happened. The backend must ensure that shared memory is registered with userfaultfd to cause faulting of non-present pages. =20 This is always sent sometime after a ``VHOST_USER_POSTCOPY_ADVISE``, @@ -1231,7 +1231,7 @@ reply is sent by the slave. :request payload: N/A :reply payload: ``u64`` =20 - Master advises that postcopy migration has now completed. The slave + The frontend advises that postcopy migration has now completed. The bac= kend must disable the userfaultfd. The reply is an acknowledgement only. =20 @@ -1248,9 +1248,9 @@ reply is sent by the slave. :reply payload: N/A =20 When ``VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD`` protocol feature has - been successfully negotiated, this message is submitted by master to - get a shared buffer from slave. The shared buffer will be used to - track inflight I/O by slave. QEMU should retrieve a new one when vm + been successfully negotiated, this message is submitted by the frontend = to + get a shared buffer from backend. The shared buffer will be used to + track inflight I/O by backend. QEMU should retrieve a new one when vm reset. =20 ``VHOST_USER_SET_INFLIGHT_FD`` @@ -1260,9 +1260,9 @@ reply is sent by the slave. :reply payload: N/A =20 When ``VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD`` protocol feature has - been successfully negotiated, this message is submitted by master to - send the shared inflight buffer back to slave so that slave could - get inflight I/O after a crash or restart. + been successfully negotiated, this message is submitted by the frontend = to + send the shared inflight buffer back to the backend so that the backend + could get inflight I/O after a crash or restart. =20 ``VHOST_USER_GPU_SET_SOCKET`` :id: 33 @@ -1271,7 +1271,7 @@ reply is sent by the slave. :reply payload: N/A =20 Sets the GPU protocol socket file descriptor, which is passed as - ancillary data. The GPU protocol is used to inform the master of + ancillary data. The GPU protocol is used to inform the frontend of rendering state and updates. See vhost-user-gpu.rst for details. =20 ``VHOST_USER_RESET_DEVICE`` @@ -1296,9 +1296,9 @@ reply is sent by the slave. =20 When the ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` protocol feature has been successfully negotiated, this message may be - submitted by the master to indicate that a buffer was added to + submitted by the frontend to indicate that a buffer was added to the vring instead of signalling it using the vring's kick file - descriptor or having the slave rely on polling. + descriptor or having the backend rely on polling. =20 The state.num field is currently reserved and must be set to 0. =20 @@ -1310,7 +1310,7 @@ reply is sent by the slave. =20 When the ``VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS`` protocol feature has been successfully negotiated, this message is submitted - by master to the slave. The slave should return the message with a + by the frontend to the backend. The backend should return the message wi= th a u64 payload containing the maximum number of memory slots for QEMU to expose to the guest. The value returned by the backend will be capped at the maximum number of ram slots which can be @@ -1324,13 +1324,13 @@ reply is sent by the slave. =20 When the ``VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS`` protocol feature has been successfully negotiated, this message is submitted - by the master to the slave. The message payload contains a memory + by the frontend to the backend. The message payload contains a memory region descriptor struct, describing a region of guest memory which - the slave device must map in. When the + the backend device must map in. When the ``VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS`` protocol feature has been successfully negotiated, along with the ``VHOST_USER_REM_MEM_REG`` message, this message is used to set and - update the memory tables of the slave device. + update the memory tables of the backend device. =20 ``VHOST_USER_REM_MEM_REG`` :id: 38 @@ -1340,13 +1340,13 @@ reply is sent by the slave. =20 When the ``VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS`` protocol feature has been successfully negotiated, this message is submitted - by the master to the slave. The message payload contains a memory + by the frontend to the backend. The message payload contains a memory region descriptor struct, describing a region of guest memory which - the slave device must unmap. When the + the backend device must unmap. When the ``VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS`` protocol feature has been successfully negotiated, along with the ``VHOST_USER_ADD_MEM_REG`` message, this message is used to set and - update the memory tables of the slave device. + update the memory tables of the backend device. =20 ``VHOST_USER_SET_STATUS`` :id: 39 @@ -1355,7 +1355,7 @@ reply is sent by the slave. :reply payload: N/A =20 When the ``VHOST_USER_PROTOCOL_F_STATUS`` protocol feature has been - successfully negotiated, this message is submitted by the master to + successfully negotiated, this message is submitted by the frontend to notify the backend with updated device status as defined in the Virtio specification. =20 @@ -1366,16 +1366,16 @@ reply is sent by the slave. :reply payload: ``u64`` =20 When the ``VHOST_USER_PROTOCOL_F_STATUS`` protocol feature has been - successfully negotiated, this message is submitted by the master to + successfully negotiated, this message is submitted by the frontend to query the backend for its device status as defined in the Virtio specification. =20 =20 -Slave message types -------------------- +Back-end message types +---------------------- =20 -For this type of message, the request is sent by the slave and the reply -is sent by the master. +For this type of message, the request is sent by the backend and the reply +is sent by the frontend. =20 ``VHOST_USER_SLAVE_IOTLB_MSG`` :id: 1 @@ -1384,9 +1384,9 @@ is sent by the master. :reply payload: N/A =20 Send IOTLB messages with ``struct vhost_iotlb_msg`` as payload. - Slave sends such requests to notify of an IOTLB miss, or an IOTLB + The backend sends such requests to notify of an IOTLB miss, or an IOTLB access failure. If ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is - negotiated, and slave set the ``VHOST_USER_NEED_REPLY`` flag, master + negotiated, and backend set the ``VHOST_USER_NEED_REPLY`` flag, the fron= tend must respond with zero when operation is successfully completed, or non-zero otherwise. This request should be send only when ``VIRTIO_F_IOMMU_PLATFORM`` feature has been successfully @@ -1399,12 +1399,12 @@ is sent by the master. :reply payload: N/A =20 When ``VHOST_USER_PROTOCOL_F_CONFIG`` is negotiated, vhost-user - slave sends such messages to notify that the virtio device's + backend sends such messages to notify that the virtio device's configuration space has changed, for those host devices which can support such feature, host driver can send ``VHOST_USER_GET_CONFIG`` - message to slave to get the latest content. If - ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, and slave set the - ``VHOST_USER_NEED_REPLY`` flag, master must respond with zero when + message to the backend to get the latest content. If + ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, and the backend sets = the + ``VHOST_USER_NEED_REPLY`` flag, the frontend must respond with zero when operation is successfully completed, or non-zero otherwise. =20 ``VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG`` @@ -1422,7 +1422,7 @@ is sent by the master. description. QEMU can mmap the file descriptor based on the size and offset to get a memory range. Registering a host notifier means mapping this memory range to the VM as the specified queue's notify - MMIO region. Slave sends this request to tell QEMU to de-register + MMIO region. The backend sends this request to tell QEMU to de-register the existing notifier if any and register the new notifier if the request is sent with a file descriptor. =20 @@ -1438,9 +1438,9 @@ is sent by the master. =20 When the ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` protocol feature has been successfully negotiated, this message may be - submitted by the slave to indicate that a buffer was used from + submitted by the backend to indicate that a buffer was used from the vring instead of signalling this using the vring's call file - descriptor or having the master relying on polling. + descriptor or having the frontend relying on polling. =20 The state.num field is currently reserved and must be set to 0. =20 @@ -1452,9 +1452,9 @@ is sent by the master. =20 When the ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` protocol feature has been successfully negotiated, this message may be - submitted by the slave to indicate that an error occurred on the + submitted by the backend to indicate that an error occurred on the specific vring, instead of signalling the error file descriptor - set by the master via ``VHOST_USER_SET_VRING_ERR``. + set by the frontend via ``VHOST_USER_SET_VRING_ERR``. =20 The state.num field is currently reserved and must be set to 0. =20 @@ -1465,12 +1465,12 @@ VHOST_USER_PROTOCOL_F_REPLY_ACK =20 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 +commands are sent over an ``ioctl()`` call and block until the backend has completed. =20 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 +backend 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. =20 @@ -1479,7 +1479,7 @@ of the command. 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. =20 -For the message types that already solicit a reply from the client, +For the message types that already solicit a reply from the backend, the presence of ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` or need_reply bit being set brings no behavioural change. (See the Communication_ section for details.) --=20 2.26.2 From nobody Fri May 17 06:54:20 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1615459193; cv=none; d=zohomail.com; s=zohoarc; b=lCUXcxgZLOLkgVZFL48QpOVZ0cxWJgC9TSRwng9ghSk/SJZRKupC+EqSe1dsup3Jz2Cq65TRNXq3SirvHMbCd7LfmalezickmIwVQNJ8unIm5EQ8qtxBjRKdQWWVXpFI5UlU1C7nEdPdA2b0tt43XFMH5u+8wcNSQiuoFqORP/s= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1615459193; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=TAodmZ+Do/ZOTZrVCcOUAmzLxA2scUdv9ira0Sq1dLM=; b=Zcm84N+sMnyaCUQ2spZQKEEAUIbAwWyUchsqCnZIzRtVSVN6x8KnGXcShUyb9AQBhwTD5mcWEVzVhf+jY+VarbdqDuX6CDc1+7WTO7mBovdhwq0cwFXSaCOPMIXF+yfDi0H7/fNFtUmwOl9sTWZr57blqwwSNiRewtPnvULL3xc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1615459193337501.69801424992977; Thu, 11 Mar 2021 02:39:53 -0800 (PST) Received: from localhost ([::1]:56718 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKIjQ-0003Tv-5N for importer@patchew.org; Thu, 11 Mar 2021 05:39:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46890) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lKIcw-0002ap-Vt for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:33:11 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:55624) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lKIct-0005f0-AT for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:33:10 -0500 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-227-4r4PHRvmOrq3ARCwdDSMzA-1; Thu, 11 Mar 2021 05:33:04 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DCCB11015C84 for ; Thu, 11 Mar 2021 10:33:03 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7778D5DF26; Thu, 11 Mar 2021 10:33:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615458786; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TAodmZ+Do/ZOTZrVCcOUAmzLxA2scUdv9ira0Sq1dLM=; b=XcBjxCVizF0K2ScFdkzHkbMoK6/EBx9p6yehDOaDirkBd1MFKdSt5qV0pu8wH22Yd0TVb3 GfDBG1WvbxGcz6tdiL7l5DT4MbQQEgq4UEgMKhuHR1YZ6rzZb7+aNtUuZZvTFmGxPHjvTK OKakVyC4ctY9sRkT7JFN5kknbZ23oJU= X-MC-Unique: 4r4PHRvmOrq3ARCwdDSMzA-1 From: Paolo Bonzini To: qemu-devel@nongnu.org Subject: [PATCH 4/7] docs: vhost-user: rename message names from "SLAVE" to "BACKEND" Date: Thu, 11 Mar 2021 05:32:47 -0500 Message-Id: <20210311103250.532191-5-pbonzini@redhat.com> In-Reply-To: <20210311103250.532191-1-pbonzini@redhat.com> References: <20210311103250.532191-1-pbonzini@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pbonzini@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=216.205.24.124; envelope-from=pbonzini@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.243, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: marcandre.lureau@redhat.com, stefanha@redhat.com, mst@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) Content-Type: text/plain; charset="utf-8" Follow the terminology that is used in the rest of the document. Signed-off-by: Paolo Bonzini Reviewed-by: Stefano Garzarella --- docs/interop/vhost-user.rst | 40 ++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst index 96be549127..84c05dfb91 100644 --- a/docs/interop/vhost-user.rst +++ b/docs/interop/vhost-user.rst @@ -290,7 +290,7 @@ in the ancillary data: * ``VHOST_USER_SET_VRING_KICK`` * ``VHOST_USER_SET_VRING_CALL`` * ``VHOST_USER_SET_VRING_ERR`` -* ``VHOST_USER_SET_SLAVE_REQ_FD`` +* ``VHOST_USER_SET_BACKEND_REQ_FD`` * ``VHOST_USER_SET_INFLIGHT_FD`` (if ``VHOST_USER_PROTOCOL_F_INFLIGHT_SHMF= D``) =20 If *frontend* is unable to send the full message or receives a wrong @@ -479,7 +479,7 @@ expected to reply with a zero payload, non-zero otherwi= se. =20 The backend relies on the backend communication channel (see :ref:`Back-end communication ` section below) to send IOTLB miss -and access failure events, by sending ``VHOST_USER_SLAVE_IOTLB_MSG`` +and access failure events, by sending ``VHOST_USER_BACKEND_IOTLB_MSG`` requests to the frontend with a ``struct vhost_iotlb_msg`` as payload. For miss events, the iotlb payload has to be filled with the miss message type (1), the I/O virtual address and the permissions @@ -503,15 +503,15 @@ Back-end communication ---------------------- =20 An optional communication channel is provided if the backend declares -``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` protocol feature, to allow the +``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` protocol feature, to allow the backend to make requests to the frontend. =20 -The fd is provided via ``VHOST_USER_SET_SLAVE_REQ_FD`` ancillary data. +The fd is provided via ``VHOST_USER_SET_BACKEND_REQ_FD`` ancillary data. =20 -A backend may then send ``VHOST_USER_SLAVE_*`` messages to the frontend +A backend may then send ``VHOST_USER_BACKEND_*`` messages to the frontend using this fd communication channel. =20 -If ``VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD`` protocol feature is +If ``VHOST_USER_PROTOCOL_F_BACKEND_SEND_FD`` protocol feature is negotiated, backend can send file descriptors (at most 8 descriptors in each message) to frontend via ancillary data using this fd communication channel. @@ -798,7 +798,7 @@ Note that due to the fact that too many messages on the= sockets can cause the sending application(s) to block, it is not advised to use this feature unless absolutely necessary. It is also considered an error to negotiate this feature without also negotiating -``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` and ``VHOST_USER_PROTOCOL_F_REPLY_ACK`= `, +``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` and ``VHOST_USER_PROTOCOL_F_REPLY_AC= K``, the former is necessary for getting a message channel from the backend to the frontend, while the latter needs to be used with the in-band notification messages to block until they are processed, both to avoid @@ -818,12 +818,12 @@ Protocol features #define VHOST_USER_PROTOCOL_F_RARP 2 #define VHOST_USER_PROTOCOL_F_REPLY_ACK 3 #define VHOST_USER_PROTOCOL_F_MTU 4 - #define VHOST_USER_PROTOCOL_F_SLAVE_REQ 5 + #define VHOST_USER_PROTOCOL_F_BACKEND_REQ 5 #define VHOST_USER_PROTOCOL_F_CROSS_ENDIAN 6 #define VHOST_USER_PROTOCOL_F_CRYPTO_SESSION 7 #define VHOST_USER_PROTOCOL_F_PAGEFAULT 8 #define VHOST_USER_PROTOCOL_F_CONFIG 9 - #define VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD 10 + #define VHOST_USER_PROTOCOL_F_BACKEND_SEND_FD 10 #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11 #define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12 #define VHOST_USER_PROTOCOL_F_RESET_DEVICE 13 @@ -1023,8 +1023,8 @@ reply is sent by the backend. in the ancillary data. This signals that polling will be used instead of waiting for the call. Note that if the protocol features ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` and - ``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` have been negotiated this message - isn't necessary as the ``VHOST_USER_SLAVE_VRING_CALL`` message can be + ``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` have been negotiated this message + isn't necessary as the ``VHOST_USER_BACKEND_VRING_CALL`` message can be used, it may however still be used to set an event file descriptor or to enable polling. =20 @@ -1041,8 +1041,8 @@ reply is sent by the backend. invalid FD flag. This flag is set when there is no file descriptor in the ancillary data. Note that if the protocol features ``VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS`` and - ``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` have been negotiated this message - isn't necessary as the ``VHOST_USER_SLAVE_VRING_ERR`` message can be + ``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` have been negotiated this message + isn't necessary as the ``VHOST_USER_BACKEND_VRING_ERR`` message can be used, it may however still be used to set an event file descriptor (which will be preferred over the message). =20 @@ -1103,7 +1103,7 @@ reply is sent by the backend. respond with zero in case the specified MTU is valid, or non-zero otherwise. =20 -``VHOST_USER_SET_SLAVE_REQ_FD`` +``VHOST_USER_SET_BACKEND_REQ_FD`` :id: 21 :equivalent ioctl: N/A :request payload: N/A @@ -1114,7 +1114,7 @@ reply is sent by the backend. =20 This request should be sent only when ``VHOST_USER_F_PROTOCOL_FEATURES`` has been negotiated, and protocol - feature bit ``VHOST_USER_PROTOCOL_F_SLAVE_REQ`` bit is present in + feature bit ``VHOST_USER_PROTOCOL_F_BACKEND_REQ`` bit is present in ``VHOST_USER_GET_PROTOCOL_FEATURES``. If ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, the backend must respond with zero for success, non-zero otherwise. @@ -1377,7 +1377,7 @@ Back-end message types For this type of message, the request is sent by the backend and the reply is sent by the frontend. =20 -``VHOST_USER_SLAVE_IOTLB_MSG`` +``VHOST_USER_BACKEND_IOTLB_MSG`` :id: 1 :equivalent ioctl: N/A (equivalent to ``VHOST_IOTLB_MSG`` message type) :request payload: ``struct vhost_iotlb_msg`` @@ -1392,7 +1392,7 @@ is sent by the frontend. ``VIRTIO_F_IOMMU_PLATFORM`` feature has been successfully negotiated. =20 -``VHOST_USER_SLAVE_CONFIG_CHANGE_MSG`` +``VHOST_USER_BACKEND_CONFIG_CHANGE_MSG`` :id: 2 :equivalent ioctl: N/A :request payload: N/A @@ -1407,7 +1407,7 @@ is sent by the frontend. ``VHOST_USER_NEED_REPLY`` flag, the frontend must respond with zero when operation is successfully completed, or non-zero otherwise. =20 -``VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG`` +``VHOST_USER_BACKEND_VRING_HOST_NOTIFIER_MSG`` :id: 3 :equivalent ioctl: N/A :request payload: vring area description @@ -1430,7 +1430,7 @@ is sent by the frontend. ``VHOST_USER_PROTOCOL_F_HOST_NOTIFIER`` protocol feature has been successfully negotiated. =20 -``VHOST_USER_SLAVE_VRING_CALL`` +``VHOST_USER_BACKEND_VRING_CALL`` :id: 4 :equivalent ioctl: N/A :request payload: vring state description @@ -1444,7 +1444,7 @@ is sent by the frontend. =20 The state.num field is currently reserved and must be set to 0. =20 -``VHOST_USER_SLAVE_VRING_ERR`` +``VHOST_USER_BACKEND_VRING_ERR`` :id: 5 :equivalent ioctl: N/A :request payload: vring state description --=20 2.26.2 From nobody Fri May 17 06:54:20 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1615459004; cv=none; d=zohomail.com; s=zohoarc; b=OKNsWoWO8pCpQ7k5EgtTJpbVf9Oko1hG6OWL3XrdYDZgQh1DOMJeT3wiZehvVlG303QeNuBRNM/Cdj1ub7bXBs4mAWxddilD4eDmUrLSlazg+EWqEC2TQdIfhCbU7FPCf3OH0+lOn6/+CBU9ZENRB1siKS9tEMfGpCX35T+yjAI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1615459004; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=hnxlQsHD1/OtTtkYAeS1gwTtMqtRpxPUf0HOhg5GQCA=; b=aYMt1QEjwWYaOMR8ozBdIaVzEwMvua/8tpMBwZAtCCUlw9BNrTWkvx0WGs1HHSsOTRA0HbCMLISGqdfmv3LiPbg9GtvOsW/V3WK5Pel7VqTs+MgN4lY8FW6OT+0Q69W2l8aZ0tlmJnJ2MqAKzcLfo5ziPlg90S1wNdd+sybCUUU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1615459004531686.7150338604736; Thu, 11 Mar 2021 02:36:44 -0800 (PST) Received: from localhost ([::1]:48342 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKIgN-000887-8e for importer@patchew.org; Thu, 11 Mar 2021 05:36:43 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46870) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lKIcw-0002Yt-00 for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:33:10 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:45443) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lKIct-0005fp-O2 for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:33:09 -0500 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-231-Rt323LmYPCSUFmj2DfVWhg-1; Thu, 11 Mar 2021 05:33:05 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6800419200C0 for ; Thu, 11 Mar 2021 10:33:04 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0277029400; Thu, 11 Mar 2021 10:33:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615458787; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hnxlQsHD1/OtTtkYAeS1gwTtMqtRpxPUf0HOhg5GQCA=; b=F8N7AgNyDO8cp90lD+EMhknu/Et9CC2ftkvTP+KguuQIH4CSToomzS8nxY8EQXs0IFeC3E OTZ4fDcVgiJQECc9yDdGsOOocZIKmjcI1LYhIX712oUSPBDSBnRrnLn2fkXjMh+QuGZJ6s X8jc9TK6M/JdfZ/waP1IGjeAzS/PIzY= X-MC-Unique: Rt323LmYPCSUFmj2DfVWhg-1 From: Paolo Bonzini To: qemu-devel@nongnu.org Subject: [PATCH 5/7] vhost-user: rename message names from "SLAVE" to "BACKEND" Date: Thu, 11 Mar 2021 05:32:48 -0500 Message-Id: <20210311103250.532191-6-pbonzini@redhat.com> In-Reply-To: <20210311103250.532191-1-pbonzini@redhat.com> References: <20210311103250.532191-1-pbonzini@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pbonzini@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=216.205.24.124; envelope-from=pbonzini@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.243, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: marcandre.lureau@redhat.com, stefanha@redhat.com, mst@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) Content-Type: text/plain; charset="utf-8" Follow the terminology that is used in the specification. Signed-off-by: Paolo Bonzini Reviewed-by: Stefano Garzarella --- hw/virtio/vhost-user.c | 96 +++++++++++++++++++++--------------------- 1 file changed, 48 insertions(+), 48 deletions(-) diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c index 2fdd5daf74..dff420fce9 100644 --- a/hw/virtio/vhost-user.c +++ b/hw/virtio/vhost-user.c @@ -37,7 +37,7 @@ =20 #define VHOST_MEMORY_BASELINE_NREGIONS 8 #define VHOST_USER_F_PROTOCOL_FEATURES 30 -#define VHOST_USER_SLAVE_MAX_FDS 8 +#define VHOST_USER_BACKEND_MAX_FDS 8 =20 /* * Set maximum number of RAM slots supported to @@ -68,12 +68,12 @@ enum VhostUserProtocolFeature { VHOST_USER_PROTOCOL_F_RARP =3D 2, VHOST_USER_PROTOCOL_F_REPLY_ACK =3D 3, VHOST_USER_PROTOCOL_F_NET_MTU =3D 4, - VHOST_USER_PROTOCOL_F_SLAVE_REQ =3D 5, + VHOST_USER_PROTOCOL_F_BACKEND_REQ =3D 5, VHOST_USER_PROTOCOL_F_CROSS_ENDIAN =3D 6, VHOST_USER_PROTOCOL_F_CRYPTO_SESSION =3D 7, VHOST_USER_PROTOCOL_F_PAGEFAULT =3D 8, VHOST_USER_PROTOCOL_F_CONFIG =3D 9, - VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD =3D 10, + VHOST_USER_PROTOCOL_F_BACKEND_SEND_FD =3D 10, VHOST_USER_PROTOCOL_F_HOST_NOTIFIER =3D 11, VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD =3D 12, VHOST_USER_PROTOCOL_F_RESET_DEVICE =3D 13, @@ -106,7 +106,7 @@ typedef enum VhostUserRequest { VHOST_USER_SET_VRING_ENABLE =3D 18, VHOST_USER_SEND_RARP =3D 19, VHOST_USER_NET_SET_MTU =3D 20, - VHOST_USER_SET_SLAVE_REQ_FD =3D 21, + VHOST_USER_SET_BACKEND_REQ_FD =3D 21, VHOST_USER_IOTLB_MSG =3D 22, VHOST_USER_SET_VRING_ENDIAN =3D 23, VHOST_USER_GET_CONFIG =3D 24, @@ -128,11 +128,11 @@ typedef enum VhostUserRequest { } VhostUserRequest; =20 typedef enum VhostUserSlaveRequest { - VHOST_USER_SLAVE_NONE =3D 0, - VHOST_USER_SLAVE_IOTLB_MSG =3D 1, - VHOST_USER_SLAVE_CONFIG_CHANGE_MSG =3D 2, - VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG =3D 3, - VHOST_USER_SLAVE_MAX + VHOST_USER_BACKEND_NONE =3D 0, + VHOST_USER_BACKEND_IOTLB_MSG =3D 1, + VHOST_USER_BACKEND_CONFIG_CHANGE_MSG =3D 2, + VHOST_USER_BACKEND_VRING_HOST_NOTIFIER_MSG =3D 3, + VHOST_USER_BACKEND_MAX } VhostUserSlaveRequest; =20 typedef struct VhostUserMemoryRegion { @@ -237,7 +237,7 @@ struct vhost_user { struct vhost_dev *dev; /* Shared between vhost devs of the same virtio device */ VhostUserState *user; - int slave_fd; + int backend_fd; NotifierWithReturn postcopy_notifier; struct PostCopyFD postcopy_fd; uint64_t postcopy_client_bases[VHOST_USER_MAX_RAM_SLOTS]; @@ -1317,7 +1317,7 @@ static int vhost_user_reset_device(struct vhost_dev *= dev) return 0; } =20 -static int vhost_user_slave_handle_config_change(struct vhost_dev *dev) +static int vhost_user_backend_handle_config_change(struct vhost_dev *dev) { int ret =3D -1; =20 @@ -1332,9 +1332,9 @@ static int vhost_user_slave_handle_config_change(stru= ct vhost_dev *dev) return ret; } =20 -static int vhost_user_slave_handle_vring_host_notifier(struct vhost_dev *d= ev, - VhostUserVringArea = *area, - int fd) +static int vhost_user_backend_handle_vring_host_notifier(struct vhost_dev = *dev, + VhostUserVringAre= a *area, + int fd) { int queue_idx =3D area->u64 & VHOST_USER_VRING_IDX_MASK; size_t page_size =3D qemu_real_host_page_size; @@ -1392,7 +1392,7 @@ static int vhost_user_slave_handle_vring_host_notifie= r(struct vhost_dev *dev, return 0; } =20 -static void slave_read(void *opaque) +static void backend_read(void *opaque) { struct vhost_dev *dev =3D opaque; struct vhost_user *u =3D dev->opaque; @@ -1401,7 +1401,7 @@ static void slave_read(void *opaque) int size, ret =3D 0; struct iovec iov; struct msghdr msgh; - int fd[VHOST_USER_SLAVE_MAX_FDS]; + int fd[VHOST_USER_BACKEND_MAX_FDS]; char control[CMSG_SPACE(sizeof(fd))]; struct cmsghdr *cmsg; int i, fdsize =3D 0; @@ -1419,11 +1419,11 @@ static void slave_read(void *opaque) iov.iov_len =3D VHOST_USER_HDR_SIZE; =20 do { - size =3D recvmsg(u->slave_fd, &msgh, 0); + size =3D recvmsg(u->backend_fd, &msgh, 0); } while (size < 0 && (errno =3D=3D EINTR || errno =3D=3D EAGAIN)); =20 if (size !=3D VHOST_USER_HDR_SIZE) { - error_report("Failed to read from slave."); + error_report("Failed to read from backend."); goto err; } =20 @@ -1451,24 +1451,24 @@ static void slave_read(void *opaque) =20 /* Read payload */ do { - size =3D read(u->slave_fd, &payload, hdr.size); + size =3D read(u->backend_fd, &payload, hdr.size); } while (size < 0 && (errno =3D=3D EINTR || errno =3D=3D EAGAIN)); =20 if (size !=3D hdr.size) { - error_report("Failed to read payload from slave."); + error_report("Failed to read payload from backend."); goto err; } =20 switch (hdr.request) { - case VHOST_USER_SLAVE_IOTLB_MSG: + case VHOST_USER_BACKEND_IOTLB_MSG: ret =3D vhost_backend_handle_iotlb_msg(dev, &payload.iotlb); break; - case VHOST_USER_SLAVE_CONFIG_CHANGE_MSG : - ret =3D vhost_user_slave_handle_config_change(dev); + case VHOST_USER_BACKEND_CONFIG_CHANGE_MSG : + ret =3D vhost_user_backend_handle_config_change(dev); break; - case VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG: - ret =3D vhost_user_slave_handle_vring_host_notifier(dev, &payload.= area, - fd[0]); + case VHOST_USER_BACKEND_VRING_HOST_NOTIFIER_MSG: + ret =3D vhost_user_backend_handle_vring_host_notifier(dev, &payloa= d.area, + fd[0]); break; default: error_report("Received unexpected msg type: %d.", hdr.request); @@ -1502,11 +1502,11 @@ static void slave_read(void *opaque) iovec[1].iov_len =3D hdr.size; =20 do { - size =3D writev(u->slave_fd, iovec, ARRAY_SIZE(iovec)); + size =3D writev(u->backend_fd, iovec, ARRAY_SIZE(iovec)); } while (size < 0 && (errno =3D=3D EINTR || errno =3D=3D EAGAIN)); =20 if (size !=3D VHOST_USER_HDR_SIZE + hdr.size) { - error_report("Failed to send msg reply to slave."); + error_report("Failed to send msg reply to backend."); goto err; } } @@ -1514,9 +1514,9 @@ static void slave_read(void *opaque) return; =20 err: - qemu_set_fd_handler(u->slave_fd, NULL, NULL, NULL); - close(u->slave_fd); - u->slave_fd =3D -1; + qemu_set_fd_handler(u->backend_fd, NULL, NULL, NULL); + close(u->backend_fd); + u->backend_fd =3D -1; for (i =3D 0; i < fdsize; i++) { if (fd[i] !=3D -1) { close(fd[i]); @@ -1525,10 +1525,10 @@ err: return; } =20 -static int vhost_setup_slave_channel(struct vhost_dev *dev) +static int vhost_setup_backend_channel(struct vhost_dev *dev) { VhostUserMsg msg =3D { - .hdr.request =3D VHOST_USER_SET_SLAVE_REQ_FD, + .hdr.request =3D VHOST_USER_SET_BACKEND_REQ_FD, .hdr.flags =3D VHOST_USER_VERSION, }; struct vhost_user *u =3D dev->opaque; @@ -1537,7 +1537,7 @@ static int vhost_setup_slave_channel(struct vhost_dev= *dev) VHOST_USER_PROTOCOL_F_REPLY_= ACK); =20 if (!virtio_has_feature(dev->protocol_features, - VHOST_USER_PROTOCOL_F_SLAVE_REQ)) { + VHOST_USER_PROTOCOL_F_BACKEND_REQ)) { return 0; } =20 @@ -1546,8 +1546,8 @@ static int vhost_setup_slave_channel(struct vhost_dev= *dev) return -1; } =20 - u->slave_fd =3D sv[0]; - qemu_set_fd_handler(u->slave_fd, slave_read, NULL, dev); + u->backend_fd =3D sv[0]; + qemu_set_fd_handler(u->backend_fd, backend_read, NULL, dev); =20 if (reply_supported) { msg.hdr.flags |=3D VHOST_USER_NEED_REPLY_MASK; @@ -1565,9 +1565,9 @@ static int vhost_setup_slave_channel(struct vhost_dev= *dev) out: close(sv[1]); if (ret) { - qemu_set_fd_handler(u->slave_fd, NULL, NULL, NULL); - close(u->slave_fd); - u->slave_fd =3D -1; + qemu_set_fd_handler(u->backend_fd, NULL, NULL, NULL); + close(u->backend_fd); + u->backend_fd =3D -1; } =20 return ret; @@ -1804,7 +1804,7 @@ static int vhost_user_backend_init(struct vhost_dev *= dev, void *opaque) =20 u =3D g_new0(struct vhost_user, 1); u->user =3D opaque; - u->slave_fd =3D -1; + u->backend_fd =3D -1; u->dev =3D dev; dev->opaque =3D u; =20 @@ -1851,11 +1851,11 @@ static int vhost_user_backend_init(struct vhost_dev= *dev, void *opaque) =20 if (virtio_has_feature(features, VIRTIO_F_IOMMU_PLATFORM) && !(virtio_has_feature(dev->protocol_features, - VHOST_USER_PROTOCOL_F_SLAVE_REQ) && + VHOST_USER_PROTOCOL_F_BACKEND_REQ) && virtio_has_feature(dev->protocol_features, VHOST_USER_PROTOCOL_F_REPLY_ACK))) { error_report("IOMMU support requires reply-ack and " - "slave-req protocol features."); + "backend-req protocol features."); return -1; } =20 @@ -1890,7 +1890,7 @@ static int vhost_user_backend_init(struct vhost_dev *= dev, void *opaque) } =20 if (dev->vq_index =3D=3D 0) { - err =3D vhost_setup_slave_channel(dev); + err =3D vhost_setup_backend_channel(dev); if (err < 0) { return err; } @@ -1919,10 +1919,10 @@ static int vhost_user_backend_cleanup(struct vhost_= dev *dev) close(u->postcopy_fd.fd); u->postcopy_fd.handler =3D NULL; } - if (u->slave_fd >=3D 0) { - qemu_set_fd_handler(u->slave_fd, NULL, NULL, NULL); - close(u->slave_fd); - u->slave_fd =3D -1; + if (u->backend_fd >=3D 0) { + qemu_set_fd_handler(u->backend_fd, NULL, NULL, NULL); + close(u->backend_fd); + u->backend_fd =3D -1; } g_free(u->region_rb); u->region_rb =3D NULL; @@ -2016,7 +2016,7 @@ static int vhost_user_net_set_mtu(struct vhost_dev *d= ev, uint16_t mtu) return -1; } =20 - /* If reply_ack supported, slave has to ack specified MTU is valid */ + /* If reply_ack supported, backend has to ack specified MTU is valid */ if (reply_supported) { return process_message_reply(dev, &msg); } --=20 2.26.2 From nobody Fri May 17 06:54:20 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1615459028; cv=none; d=zohomail.com; s=zohoarc; b=imxP2jezR5ZJowd0xCa/50rX0pVo4+xPdBnuXUhLReybDQGN90nZrmAKWvQA7RxPIHW7GXHhe+WJHADScSEsOnhyvrAhmoIz6iuHdaA1mHOzeK630zUp0XXTkHsTL0DtfneATnLEomPArtu3vwnQFwtrNbGX/cMkGahmaO3Se1o= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1615459028; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=Ee/ei1R0l+B+WJ02Vfu6Jfsbjt7pu4p5m+kBDVjIUsI=; b=AC5G0sKXeeiYLF517uXcENAxQ5hVUGQGNznabXQUdKEJiuMLbTht/pvCYA8felwrr8CXW/PXDYG1SdlhFRiLSfC6nCxWz8j+/Vgwmi9Uuut6o0RZlUyqWnzST/LYH/yiXoiF93hkV+IJSEjB3y13WFEsZt8FARUawAjR5IxBqvg= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1615459028430155.51448312733726; Thu, 11 Mar 2021 02:37:08 -0800 (PST) Received: from localhost ([::1]:50688 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKIgl-0000jC-D8 for importer@patchew.org; Thu, 11 Mar 2021 05:37:07 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46888) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lKIcw-0002a2-Im for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:33:10 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:45315) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lKIcu-0005gV-Kn for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:33:10 -0500 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-362-k5_VQ9dKPyaJQiSwo0ekUA-1; Thu, 11 Mar 2021 05:33:05 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E7A1E10866A5 for ; Thu, 11 Mar 2021 10:33:04 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 81E951B5AD; Thu, 11 Mar 2021 10:33:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615458787; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ee/ei1R0l+B+WJ02Vfu6Jfsbjt7pu4p5m+kBDVjIUsI=; b=TGAm0DGU2xbXzuFRjRNLzka3ig2s8B1Lx0j7qLIaj2g5O3p0z0z0H3KdHhfs0JWjQEUw5C BHZsvhmDmkaGStkdaY31dDRlrJPaFtwQR1XEb9CKCsA9pDEVcdFhJBRn9ZazZ5z8c26U16 iregThmLfxhtBR428bkEroATQWjMcvU= X-MC-Unique: k5_VQ9dKPyaJQiSwo0ekUA-1 From: Paolo Bonzini To: qemu-devel@nongnu.org Subject: [PATCH 6/7] libvhost-user: rename message names from "SLAVE" to "BACKEND" Date: Thu, 11 Mar 2021 05:32:49 -0500 Message-Id: <20210311103250.532191-7-pbonzini@redhat.com> In-Reply-To: <20210311103250.532191-1-pbonzini@redhat.com> References: <20210311103250.532191-1-pbonzini@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pbonzini@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=63.128.21.124; envelope-from=pbonzini@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.243, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UPPERCASE_50_75=0.008 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: marcandre.lureau@redhat.com, stefanha@redhat.com, mst@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) Content-Type: text/plain; charset="utf-8" Follow the terminology that is used in the specification. The old names are preserved for API compatibility. Signed-off-by: Paolo Bonzini Reviewed-by: Stefano Garzarella --- subprojects/libvhost-user/libvhost-user.c | 20 ++++++------ subprojects/libvhost-user/libvhost-user.h | 39 ++++++++++++++++------- 2 files changed, 37 insertions(+), 22 deletions(-) diff --git a/subprojects/libvhost-user/libvhost-user.c b/subprojects/libvho= st-user/libvhost-user.c index fab7ca17ee..b7aef17e4e 100644 --- a/subprojects/libvhost-user/libvhost-user.c +++ b/subprojects/libvhost-user/libvhost-user.c @@ -125,7 +125,7 @@ vu_request_to_string(unsigned int req) REQ(VHOST_USER_SET_VRING_ENABLE), REQ(VHOST_USER_SEND_RARP), REQ(VHOST_USER_NET_SET_MTU), - REQ(VHOST_USER_SET_SLAVE_REQ_FD), + REQ(VHOST_USER_SET_BACKEND_REQ_FD), REQ(VHOST_USER_IOTLB_MSG), REQ(VHOST_USER_SET_VRING_ENDIAN), REQ(VHOST_USER_GET_CONFIG), @@ -1313,7 +1313,7 @@ bool vu_set_queue_host_notifier(VuDev *dev, VuVirtq *= vq, int fd, int qidx =3D vq - dev->vq; int fd_num =3D 0; VhostUserMsg vmsg =3D { - .request =3D VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG, + .request =3D VHOST_USER_BACKEND_VRING_HOST_NOTIFIER_MSG, .flags =3D VHOST_USER_VERSION | VHOST_USER_NEED_REPLY_MASK, .size =3D sizeof(vmsg.payload.area), .payload.area =3D { @@ -1331,7 +1331,7 @@ bool vu_set_queue_host_notifier(VuDev *dev, VuVirtq *= vq, int fd, =20 vmsg.fd_num =3D fd_num; =20 - if (!vu_has_protocol_feature(dev, VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD)= ) { + if (!vu_has_protocol_feature(dev, VHOST_USER_PROTOCOL_F_BACKEND_SEND_F= D)) { return false; } =20 @@ -1409,9 +1409,9 @@ vu_get_protocol_features_exec(VuDev *dev, VhostUserMs= g *vmsg) */ uint64_t features =3D 1ULL << VHOST_USER_PROTOCOL_F_MQ | 1ULL << VHOST_USER_PROTOCOL_F_LOG_SHMFD | - 1ULL << VHOST_USER_PROTOCOL_F_SLAVE_REQ | + 1ULL << VHOST_USER_PROTOCOL_F_BACKEND_REQ | 1ULL << VHOST_USER_PROTOCOL_F_HOST_NOTIFIER | - 1ULL << VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD | + 1ULL << VHOST_USER_PROTOCOL_F_BACKEND_SEND_FD | 1ULL << VHOST_USER_PROTOCOL_F_REPLY_ACK | 1ULL << VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS; =20 @@ -1442,7 +1442,7 @@ vu_set_protocol_features_exec(VuDev *dev, VhostUserMs= g *vmsg) =20 if (vu_has_protocol_feature(dev, VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS= ) && - (!vu_has_protocol_feature(dev, VHOST_USER_PROTOCOL_F_SLAVE_REQ) || + (!vu_has_protocol_feature(dev, VHOST_USER_PROTOCOL_F_BACKEND_REQ) = || !vu_has_protocol_feature(dev, VHOST_USER_PROTOCOL_F_REPLY_ACK))) { /* * The use case for using messages for kick/call is simulation, to= make @@ -1455,7 +1455,7 @@ vu_set_protocol_features_exec(VuDev *dev, VhostUserMs= g *vmsg) * that actually enables the simulation case. */ vu_panic(dev, - "F_IN_BAND_NOTIFICATIONS requires F_SLAVE_REQ && F_REPLY_= ACK"); + "F_IN_BAND_NOTIFICATIONS requires F_BACKEND_REQ && F_REPL= Y_ACK"); return false; } =20 @@ -1864,7 +1864,7 @@ vu_process_message(VuDev *dev, VhostUserMsg *vmsg) return vu_get_queue_num_exec(dev, vmsg); case VHOST_USER_SET_VRING_ENABLE: return vu_set_vring_enable_exec(dev, vmsg); - case VHOST_USER_SET_SLAVE_REQ_FD: + case VHOST_USER_SET_BACKEND_REQ_FD: return vu_set_slave_req_fd(dev, vmsg); case VHOST_USER_GET_CONFIG: return vu_get_config(dev, vmsg); @@ -2370,9 +2370,9 @@ static void _vu_queue_notify(VuDev *dev, VuVirtq *vq,= bool sync) if (vq->call_fd < 0 && vu_has_protocol_feature(dev, VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS= ) && - vu_has_protocol_feature(dev, VHOST_USER_PROTOCOL_F_SLAVE_REQ)) { + vu_has_protocol_feature(dev, VHOST_USER_PROTOCOL_F_BACKEND_REQ)) { VhostUserMsg vmsg =3D { - .request =3D VHOST_USER_SLAVE_VRING_CALL, + .request =3D VHOST_USER_BACKEND_VRING_CALL, .flags =3D VHOST_USER_VERSION, .size =3D sizeof(vmsg.payload.state), .payload.state =3D { diff --git a/subprojects/libvhost-user/libvhost-user.h b/subprojects/libvho= st-user/libvhost-user.h index 3d13dfadde..eba3e1fc05 100644 --- a/subprojects/libvhost-user/libvhost-user.h +++ b/subprojects/libvhost-user/libvhost-user.h @@ -54,18 +54,20 @@ enum VhostUserProtocolFeature { VHOST_USER_PROTOCOL_F_RARP =3D 2, VHOST_USER_PROTOCOL_F_REPLY_ACK =3D 3, VHOST_USER_PROTOCOL_F_NET_MTU =3D 4, - VHOST_USER_PROTOCOL_F_SLAVE_REQ =3D 5, + VHOST_USER_PROTOCOL_F_BACKEND_REQ =3D 5, VHOST_USER_PROTOCOL_F_CROSS_ENDIAN =3D 6, VHOST_USER_PROTOCOL_F_CRYPTO_SESSION =3D 7, VHOST_USER_PROTOCOL_F_PAGEFAULT =3D 8, VHOST_USER_PROTOCOL_F_CONFIG =3D 9, - VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD =3D 10, + VHOST_USER_PROTOCOL_F_BACKEND_SEND_FD =3D 10, VHOST_USER_PROTOCOL_F_HOST_NOTIFIER =3D 11, VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD =3D 12, VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS =3D 14, VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS =3D 15, + VHOST_USER_PROTOCOL_F_MAX, =20 - VHOST_USER_PROTOCOL_F_MAX + VHOST_USER_PROTOCOL_F_SLAVE_REQ =3D VHOST_USER_PROTOCOL_F_BACKEND_REQ, + VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD =3D VHOST_USER_PROTOCOL_F_BACKEND_= SEND_FD }; =20 #define VHOST_USER_PROTOCOL_FEATURE_MASK ((1 << VHOST_USER_PROTOCOL_F_MAX)= - 1) @@ -92,7 +94,7 @@ typedef enum VhostUserRequest { VHOST_USER_SET_VRING_ENABLE =3D 18, VHOST_USER_SEND_RARP =3D 19, VHOST_USER_NET_SET_MTU =3D 20, - VHOST_USER_SET_SLAVE_REQ_FD =3D 21, + VHOST_USER_SET_BACKEND_REQ_FD =3D 21, VHOST_USER_IOTLB_MSG =3D 22, VHOST_USER_SET_VRING_ENDIAN =3D 23, VHOST_USER_GET_CONFIG =3D 24, @@ -109,16 +111,29 @@ typedef enum VhostUserRequest { VHOST_USER_GET_MAX_MEM_SLOTS =3D 36, VHOST_USER_ADD_MEM_REG =3D 37, VHOST_USER_REM_MEM_REG =3D 38, - VHOST_USER_MAX + VHOST_USER_MAX, + + VHOST_USER_SET_SLAVE_REQ_FD =3D VHOST_USER_SET_BACKEND_REQ_FD, } VhostUserRequest; =20 +typedef enum VhostUserBackendRequest { + VHOST_USER_BACKEND_NONE =3D 0, + VHOST_USER_BACKEND_IOTLB_MSG =3D 1, + VHOST_USER_BACKEND_CONFIG_CHANGE_MSG =3D 2, + VHOST_USER_BACKEND_VRING_HOST_NOTIFIER_MSG =3D 3, + VHOST_USER_BACKEND_VRING_CALL =3D 4, + VHOST_USER_BACKEND_VRING_ERR =3D 5, + VHOST_USER_BACKEND_MAX +} VhostUserBackendRequest; + + typedef enum VhostUserSlaveRequest { - VHOST_USER_SLAVE_NONE =3D 0, - VHOST_USER_SLAVE_IOTLB_MSG =3D 1, - VHOST_USER_SLAVE_CONFIG_CHANGE_MSG =3D 2, - VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG =3D 3, - VHOST_USER_SLAVE_VRING_CALL =3D 4, - VHOST_USER_SLAVE_VRING_ERR =3D 5, + VHOST_USER_SLAVE_NONE =3D VHOST_USER_BACKEND_NONE, + VHOST_USER_SLAVE_IOTLB_MSG =3D VHOST_USER_BACKEND_IOTLB_MSG, + VHOST_USER_SLAVE_CONFIG_CHANGE_MSG =3D VHOST_USER_BACKEND_CONFIG_CHANG= E_MSG, + VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG =3D VHOST_USER_BACKEND_VRING_= HOST_NOTIFIER_MSG, + VHOST_USER_SLAVE_VRING_CALL =3D VHOST_USER_BACKEND_VRING_CALL, + VHOST_USER_SLAVE_VRING_ERR =3D VHOST_USER_BACKEND_VRING_ERR, VHOST_USER_SLAVE_MAX } VhostUserSlaveRequest; =20 @@ -295,7 +310,7 @@ typedef struct VuVirtqInflight { uint16_t version; =20 /* The size of VuDescStateSplit array. It's equal to the virtqueue - * size. Slave could get it from queue size field of VhostUserInflight= . */ + * size. The backend could get it from queue size field of VhostUserIn= flight. */ uint16_t desc_num; =20 /* The head of list that track the last batch of used descriptors. */ --=20 2.26.2 From nobody Fri May 17 06:54:20 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1615459140; cv=none; d=zohomail.com; s=zohoarc; b=n9U6r5O985sPLAPgXn9rKvStG+DI4/QsDi0RelTBVeuYXbegXDY9abYfb3gLatcRBsFgqnYihZk+SbZlAY7Nz9UhA7GamRMjQbLGFiP84BO8lY0i0URh3WbqX0NvZPcm/pE3u6lT7S9m/WsLMO/FfB2VR/YnmBJe5jmOST21OO8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1615459140; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=+fYKx2ieK1/tYfA5vuFEOCC31lx6aOsd0QKKtmT39dk=; b=TTm1EZDlaisQ0TqwGbSTXefr9EPr0m6n1x+W7q8aZOEhemjEpyyIrCtQfVTZxzAky3AVxvhX8WAEacly47aWg7rHJtETh7NJC5ECrW7Eli55sltMcz2b7zdz0BoXmO94yfraVONSlKeqoZTsNJzHhWOUVl0+jFQ9jOY6OokiGOU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1615459140808358.8545702637233; Thu, 11 Mar 2021 02:39:00 -0800 (PST) Received: from localhost ([::1]:54930 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKIiZ-0002fh-FE for importer@patchew.org; Thu, 11 Mar 2021 05:38:59 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46896) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lKIcy-0002dc-5F for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:33:12 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:29935) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lKIcv-0005ge-AU for qemu-devel@nongnu.org; Thu, 11 Mar 2021 05:33:11 -0500 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-527-Ooj-1acfP9OWZ9Knsh3KaQ-1; Thu, 11 Mar 2021 05:33:06 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 74227802B4F for ; Thu, 11 Mar 2021 10:33:05 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0DA275DEF9; Thu, 11 Mar 2021 10:33:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615458788; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+fYKx2ieK1/tYfA5vuFEOCC31lx6aOsd0QKKtmT39dk=; b=hJQM78aPZXPW9rPXOJJgflHhD+jOhxq3tGvdfHyBs/YdqZX4UHCB3xfNVT9+7e5glPfrww mrEDLgIWTR+Sub0HYJM2/VoePSJfVi5V2A9+mcbX891wiClmotv9D0Ho36ZEuo6V0dufY7 HeJwQaxfzPQi0lR6XWfsR/KORpwjFjs= X-MC-Unique: Ooj-1acfP9OWZ9Knsh3KaQ-1 From: Paolo Bonzini To: qemu-devel@nongnu.org Subject: [PATCH 7/7] libvhost-user: rename struct VuDev fields from "slave" to "backend" Date: Thu, 11 Mar 2021 05:32:50 -0500 Message-Id: <20210311103250.532191-8-pbonzini@redhat.com> In-Reply-To: <20210311103250.532191-1-pbonzini@redhat.com> References: <20210311103250.532191-1-pbonzini@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pbonzini@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=216.205.24.124; envelope-from=pbonzini@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.243, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: marcandre.lureau@redhat.com, stefanha@redhat.com, mst@redhat.com Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) Content-Type: text/plain; charset="utf-8" Technically these are parts of the API, but the file descriptor seems to be managed by libvhost-user itself only. Nevertheless, I am keeping this as a separate change. Signed-off-by: Paolo Bonzini Reviewed-by: Stefano Garzarella --- subprojects/libvhost-user/libvhost-user.c | 46 +++++++++++------------ subprojects/libvhost-user/libvhost-user.h | 6 +-- 2 files changed, 26 insertions(+), 26 deletions(-) diff --git a/subprojects/libvhost-user/libvhost-user.c b/subprojects/libvho= st-user/libvhost-user.c index b7aef17e4e..53fa8b8f38 100644 --- a/subprojects/libvhost-user/libvhost-user.c +++ b/subprojects/libvhost-user/libvhost-user.c @@ -400,8 +400,8 @@ vu_send_reply(VuDev *dev, int conn_fd, VhostUserMsg *vm= sg) } =20 /* - * Processes a reply on the slave channel. - * Entered with slave_mutex held and releases it before exit. + * Processes a reply from the frontend on the backend channel. + * Entered with backend_mutex held and releases it before exit. * Returns true on success. */ static bool @@ -415,7 +415,7 @@ vu_process_message_reply(VuDev *dev, const VhostUserMsg= *vmsg) goto out; } =20 - if (!vu_message_read_default(dev, dev->slave_fd, &msg_reply)) { + if (!vu_message_read_default(dev, dev->backend_fd, &msg_reply)) { goto out; } =20 @@ -428,7 +428,7 @@ vu_process_message_reply(VuDev *dev, const VhostUserMsg= *vmsg) result =3D msg_reply.payload.u64 =3D=3D 0; =20 out: - pthread_mutex_unlock(&dev->slave_mutex); + pthread_mutex_unlock(&dev->backend_mutex); return result; } =20 @@ -1335,13 +1335,13 @@ bool vu_set_queue_host_notifier(VuDev *dev, VuVirtq= *vq, int fd, return false; } =20 - pthread_mutex_lock(&dev->slave_mutex); - if (!vu_message_write(dev, dev->slave_fd, &vmsg)) { - pthread_mutex_unlock(&dev->slave_mutex); + pthread_mutex_lock(&dev->backend_mutex); + if (!vu_message_write(dev, dev->backend_fd, &vmsg)) { + pthread_mutex_unlock(&dev->backend_mutex); return false; } =20 - /* Also unlocks the slave_mutex */ + /* Also unlocks the backend_mutex */ return vu_process_message_reply(dev, &vmsg); } =20 @@ -1492,18 +1492,18 @@ vu_set_vring_enable_exec(VuDev *dev, VhostUserMsg *= vmsg) } =20 static bool -vu_set_slave_req_fd(VuDev *dev, VhostUserMsg *vmsg) +vu_set_backend_req_fd(VuDev *dev, VhostUserMsg *vmsg) { if (vmsg->fd_num !=3D 1) { - vu_panic(dev, "Invalid slave_req_fd message (%d fd's)", vmsg->fd_n= um); + vu_panic(dev, "Invalid backend_req_fd message (%d fd's)", vmsg->fd= _num); return false; } =20 - if (dev->slave_fd !=3D -1) { - close(dev->slave_fd); + if (dev->backend_fd !=3D -1) { + close(dev->backend_fd); } - dev->slave_fd =3D vmsg->fds[0]; - DPRINT("Got slave_fd: %d\n", vmsg->fds[0]); + dev->backend_fd =3D vmsg->fds[0]; + DPRINT("Got backend_fd: %d\n", vmsg->fds[0]); =20 return false; } @@ -1865,7 +1865,7 @@ vu_process_message(VuDev *dev, VhostUserMsg *vmsg) case VHOST_USER_SET_VRING_ENABLE: return vu_set_vring_enable_exec(dev, vmsg); case VHOST_USER_SET_BACKEND_REQ_FD: - return vu_set_slave_req_fd(dev, vmsg); + return vu_set_backend_req_fd(dev, vmsg); case VHOST_USER_GET_CONFIG: return vu_get_config(dev, vmsg); case VHOST_USER_SET_CONFIG: @@ -1986,11 +1986,11 @@ vu_deinit(VuDev *dev) } =20 vu_close_log(dev); - if (dev->slave_fd !=3D -1) { - close(dev->slave_fd); - dev->slave_fd =3D -1; + if (dev->backend_fd !=3D -1) { + close(dev->backend_fd); + dev->backend_fd =3D -1; } - pthread_mutex_destroy(&dev->slave_mutex); + pthread_mutex_destroy(&dev->backend_mutex); =20 if (dev->sock !=3D -1) { close(dev->sock); @@ -2028,8 +2028,8 @@ vu_init(VuDev *dev, dev->remove_watch =3D remove_watch; dev->iface =3D iface; dev->log_call_fd =3D -1; - pthread_mutex_init(&dev->slave_mutex, NULL); - dev->slave_fd =3D -1; + pthread_mutex_init(&dev->backend_mutex, NULL); + dev->backend_fd =3D -1; dev->max_queues =3D max_queues; =20 dev->vq =3D malloc(max_queues * sizeof(dev->vq[0])); @@ -2387,9 +2387,9 @@ static void _vu_queue_notify(VuDev *dev, VuVirtq *vq,= bool sync) vmsg.flags |=3D VHOST_USER_NEED_REPLY_MASK; } =20 - vu_message_write(dev, dev->slave_fd, &vmsg); + vu_message_write(dev, dev->backend_fd, &vmsg); if (ack) { - vu_message_read_default(dev, dev->slave_fd, &vmsg); + vu_message_read_default(dev, dev->backend_fd, &vmsg); } return; } diff --git a/subprojects/libvhost-user/libvhost-user.h b/subprojects/libvho= st-user/libvhost-user.h index eba3e1fc05..f29cbf4754 100644 --- a/subprojects/libvhost-user/libvhost-user.h +++ b/subprojects/libvhost-user/libvhost-user.h @@ -397,9 +397,9 @@ struct VuDev { VuVirtq *vq; VuDevInflightInfo inflight_info; int log_call_fd; - /* Must be held while using slave_fd */ - pthread_mutex_t slave_mutex; - int slave_fd; + /* Must be held while using backend */ + pthread_mutex_t backend_mutex; + int backend_fd; uint64_t log_size; uint8_t *log_table; uint64_t features; --=20 2.26.2