{"id":2198136,"url":"http://patchwork.ozlabs.org/api/1.0/patches/2198136/?format=json","project":{"id":14,"url":"http://patchwork.ozlabs.org/api/1.0/projects/14/?format=json","name":"QEMU Development","link_name":"qemu-devel","list_id":"qemu-devel.nongnu.org","list_email":"qemu-devel@nongnu.org","web_url":"","scm_url":"","webscm_url":""},"msgid":"<20260219130334.787858-4-aesteve@redhat.com>","date":"2026-02-19T13:03:30","name":"[v13,3/7] vhost_user.rst: Add SHMEM_MAP/_UNMAP to spec","commit_ref":null,"pull_url":null,"state":"new","archived":false,"hash":"5330b7af42b99395d0789866fbe0a66e8a4889ad","submitter":{"id":85915,"url":"http://patchwork.ozlabs.org/api/1.0/people/85915/?format=json","name":"Albert Esteve","email":"aesteve@redhat.com"},"delegate":null,"mbox":"http://patchwork.ozlabs.org/project/qemu-devel/patch/20260219130334.787858-4-aesteve@redhat.com/mbox/","series":[{"id":492672,"url":"http://patchwork.ozlabs.org/api/1.0/series/492672/?format=json","date":"2026-02-19T13:03:27","name":"vhost-user: Add SHMEM_MAP/UNMAP requests","version":13,"mbox":"http://patchwork.ozlabs.org/series/492672/mbox/"}],"check":"pending","checks":"http://patchwork.ozlabs.org/api/patches/2198136/checks/","tags":{},"headers":{"Return-Path":"<qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=PKYjlrlj;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fGtr60wchz1xvg\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 20 Feb 2026 00:04:22 +1100 (AEDT)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from <qemu-devel-bounces@nongnu.org>)\n\tid 1vt3hU-0007cB-2B; Thu, 19 Feb 2026 08:04:12 -0500","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from <aesteve@redhat.com>)\n id 1vt3hT-0007c3-3W\n for qemu-devel@nongnu.org; Thu, 19 Feb 2026 08:04:11 -0500","from us-smtp-delivery-124.mimecast.com ([170.10.129.124])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from <aesteve@redhat.com>)\n id 1vt3hR-0006Kd-CX\n for qemu-devel@nongnu.org; Thu, 19 Feb 2026 08:04:10 -0500","from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com\n (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by\n relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,\n cipher=TLS_AES_256_GCM_SHA384) id us-mta-563-xMDpuZQSMIKUB2q0hilJxg-1; Thu,\n 19 Feb 2026 08:04:05 -0500","from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com\n (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id 7B061195609E; Thu, 19 Feb 2026 13:04:03 +0000 (UTC)","from fedora.redhat.com (unknown [10.44.33.19])\n by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP\n id 3CA6A19560A7; Thu, 19 Feb 2026 13:03:56 +0000 (UTC)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1771506248;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=xrDVJ9/PE/1violyKlt4ifA2uIEJBTc29t2K04NQynE=;\n b=PKYjlrlj2a44GHlZXYcroi3i1Kf+yu26c0AymFmS2xM9JsyS0ZjbrmcQ2BN2yAbQYieSya\n 45oKBAuja5YdiKfLtrQjMpSO0dMzUaZhfHfXErbk9YcL/xVRdG9+mf5jwUF/Oi+UXO7R7V\n SAxNrixS5nP0vnO+qfk2/Dvb5JhioM4=","X-MC-Unique":"xMDpuZQSMIKUB2q0hilJxg-1","X-Mimecast-MFC-AGG-ID":"xMDpuZQSMIKUB2q0hilJxg_1771506244","From":"Albert Esteve <aesteve@redhat.com>","To":"qemu-devel@nongnu.org","Cc":"Peter Xu <peterx@redhat.com>,\n Pierrick Bouvier <pierrick.bouvier@linaro.org>, mst@redhat.com,\n dbassey@redhat.com,\n =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= <philmd@linaro.org>, =?utf-8?q?Alex?=\n\t=?utf-8?q?_Benn=C3=A9e?= <alex.bennee@linaro.org>,\n Paolo Bonzini <pbonzini@redhat.com>, Fabiano Rosas <farosas@suse.de>,\n stefanha@redhat.com, manos.pitsidianakis@linaro.org,\n Stefano Garzarella <sgarzare@redhat.com>, jasowang@redhat.com,\n Laurent Vivier <lvivier@redhat.com>, slp@redhat.com, hi@alyssa.is,\n stevensd@chromium.org","Subject":"[PATCH v13 3/7] vhost_user.rst: Add SHMEM_MAP/_UNMAP to spec","Date":"Thu, 19 Feb 2026 14:03:30 +0100","Message-ID":"<20260219130334.787858-4-aesteve@redhat.com>","In-Reply-To":"<20260219130334.787858-1-aesteve@redhat.com>","References":"<20260219130334.787858-1-aesteve@redhat.com>","MIME-Version":"1.0","Content-Transfer-Encoding":"8bit","X-Scanned-By":"MIMEDefang 3.0 on 10.30.177.12","Received-SPF":"pass client-ip=170.10.129.124; envelope-from=aesteve@redhat.com;\n helo=us-smtp-delivery-124.mimecast.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.045,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,\n RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001,\n RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,\n SPF_HELO_PASS=-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.29","Precedence":"list","List-Id":"qemu development <qemu-devel.nongnu.org>","List-Unsubscribe":"<https://lists.nongnu.org/mailman/options/qemu-devel>,\n <mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>","List-Archive":"<https://lists.nongnu.org/archive/html/qemu-devel>","List-Post":"<mailto:qemu-devel@nongnu.org>","List-Help":"<mailto:qemu-devel-request@nongnu.org?subject=help>","List-Subscribe":"<https://lists.nongnu.org/mailman/listinfo/qemu-devel>,\n <mailto:qemu-devel-request@nongnu.org?subject=subscribe>","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"},"content":"Add SHMEM_MAP/_UNMAP request to the vhost-user\nspec documentation.\n\nReviewed-by: Stefan Hajnoczi <stefanha@redhat.com>\nReviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>\nSigned-off-by: Albert Esteve <aesteve@redhat.com>\n---\n docs/interop/vhost-user.rst | 61 +++++++++++++++++++++++++++++++++++++\n 1 file changed, 61 insertions(+)","diff":"diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst\nindex 17a68a62eb..ae4ad6f441 100644\n--- a/docs/interop/vhost-user.rst\n+++ b/docs/interop/vhost-user.rst\n@@ -350,6 +350,27 @@ Device state transfer parameters\n   In the future, additional phases might be added e.g. to allow\n   iterative migration while the device is running.\n \n+MMAP request\n+^^^^^^^^^^^^\n+\n++-------+---------+-----------+------------+-----+-------+\n+| shmid | padding | fd_offset | shm_offset | len | flags |\n++-------+---------+-----------+------------+-----+-------+\n+\n+:shmid: a 8-bit shared memory region identifier\n+\n+:fd_offset: a 64-bit offset of this area from the start\n+            of the supplied file descriptor\n+\n+:shm_offset: a 64-bit offset from the start of the\n+             pointed shared memory region\n+\n+:len: a 64-bit size of the memory to map\n+\n+:flags: a 64-bit value:\n+  - 0: Pages are mapped read-only\n+  - 1: Pages are mapped read-write\n+\n C structure\n -----------\n \n@@ -375,6 +396,7 @@ In QEMU the vhost-user message is implemented with the following struct:\n           VhostUserInflight inflight;\n           VhostUserShared object;\n           VhostUserTransferDeviceState transfer_state;\n+          VhostUserMMap mmap;\n       };\n   } QEMU_PACKED VhostUserMsg;\n \n@@ -1064,6 +1086,7 @@ Protocol features\n   #define VHOST_USER_PROTOCOL_F_XEN_MMAP             17\n   #define VHOST_USER_PROTOCOL_F_SHARED_OBJECT        18\n   #define VHOST_USER_PROTOCOL_F_DEVICE_STATE         19\n+  #define VHOST_USER_PROTOCOL_F_SHMEM                20\n \n Front-end message types\n -----------------------\n@@ -1872,6 +1895,44 @@ is sent by the front-end.\n   when the operation is successful, or non-zero otherwise. Note that if the\n   operation fails, no fd is sent to the backend.\n \n+``VHOST_USER_BACKEND_SHMEM_MAP``\n+  :id: 9\n+  :equivalent ioctl: N/A\n+  :request payload: fd and ``struct VhostUserMMap``\n+  :reply payload: N/A\n+\n+  When the ``VHOST_USER_PROTOCOL_F_SHMEM`` protocol feature has been\n+  successfully negotiated, this message can be submitted by the backends to\n+  advertise a new mapping to be made in a given VIRTIO Shared Memory Region.\n+  Upon receiving the message, the front-end will mmap the given fd into the\n+  VIRTIO Shared Memory Region with the requested ``shmid``.\n+  If ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, and\n+  back-end set the ``VHOST_USER_NEED_REPLY`` flag, the front-end\n+  must respond with zero when operation is successfully completed,\n+  or non-zero otherwise.\n+\n+  Mapping over an already existing map is not allowed and requests shall fail.\n+  Therefore, the memory range in the request must correspond with a valid,\n+  free region of the VIRTIO Shared Memory Region. Also, note that mappings\n+  consume resources and that the request can fail when there are no resources\n+  available. Lastly, mappings are automatically unmapped by the front-end\n+  across device reset operation.\n+\n+``VHOST_USER_BACKEND_SHMEM_UNMAP``\n+  :id: 10\n+  :equivalent ioctl: N/A\n+  :request payload: ``struct VhostUserMMap``\n+  :reply payload: N/A\n+\n+  When the ``VHOST_USER_PROTOCOL_F_SHMEM`` protocol feature has been\n+  successfully negotiated, this message can be submitted by the backends so\n+  that the front-end un-mmaps a given range (``shm_offset``, ``len``) in the\n+  VIRTIO Shared Memory Region with the requested ``shmid``. Note that the\n+  given range shall correspond to the entirety of a valid mapped region.\n+  If ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, and the back-end\n+  sets the ``VHOST_USER_NEED_REPLY`` flag, the front-end must respond with\n+  zero when operation is successfully completed, or non-zero otherwise.\n+\n .. _reply_ack:\n \n VHOST_USER_PROTOCOL_F_REPLY_ACK\n","prefixes":["v13","3/7"]}