From nobody Fri May 10 20:10:55 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=linaro.org ARC-Seal: i=1; a=rsa-sha256; t=1676973099; cv=none; d=zohomail.com; s=zohoarc; b=c88toW8ef2DsUgrcqrWVCuds0FMLF37M6ko8qyYEoDkbPGxudBy7w1AWLynexPOYvImdjGfgAkWoSgJyEkvqzEuFvsOXsIIyU6Llbp/Kzyz5/oxKRk1Z9q+VWWTKD5ncJb0XWp2E7cO4IrZj2Rx3tqwzvIKyy0P3PrHYFSfKmvo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1676973099; h=Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=wNQkeraNsuw6hFISAboGasHi5jkq9Qw1lk2C7Y7QJNM=; b=WugNMtjf6JUTJViJepirAXejoK3PmEGDD8xXzm5sBY+NknvSR4kHhzqmsbYlayZNXaG1nR/GWkwKZPOnkIvhto170Gcf85ymzyGL1nqkYaR+ur7eJivmgCp65G4Dzb1Wc1+PwJIdufpc3m7l1O5ZUJH03wtuTvnzscPL7JoY5zw= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1676973099482520.4155366245772; Tue, 21 Feb 2023 01:51:39 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.498694.769571 (Exim 4.92) (envelope-from ) id 1pUPIm-0005cf-Dh; Tue, 21 Feb 2023 09:51:12 +0000 Received: by outflank-mailman (output) from mailman id 498694.769571; Tue, 21 Feb 2023 09:51:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pUPIm-0005cY-AW; Tue, 21 Feb 2023 09:51:12 +0000 Received: by outflank-mailman (input) for mailman id 498694; Tue, 21 Feb 2023 09:51:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pUPIl-00055b-SN for xen-devel@lists.xen.org; Tue, 21 Feb 2023 09:51:12 +0000 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [2607:f8b0:4864:20::102d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2aa5f70d-b1cd-11ed-93b6-47a8fe42b414; Tue, 21 Feb 2023 10:50:28 +0100 (CET) Received: by mail-pj1-x102d.google.com with SMTP id na9-20020a17090b4c0900b0023058bbd7b2so4114919pjb.0 for ; Tue, 21 Feb 2023 01:51:03 -0800 (PST) Received: from localhost ([122.172.83.155]) by smtp.gmail.com with ESMTPSA id 17-20020a170902c21100b00199190b00efsm9493493pll.97.2023.02.21.01.51.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Feb 2023 01:51:01 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2aa5f70d-b1cd-11ed-93b6-47a8fe42b414 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=wNQkeraNsuw6hFISAboGasHi5jkq9Qw1lk2C7Y7QJNM=; b=Sp7J+0CTBva8aEj2O9RPa7/fe/vPPgO/x/0R35WMCIEt+K5/CuaIDpJV5pICjBM3i/ 7+YqI+uYKU28wB0J6rXEsxFspuixkueTtJC1QuHP618WlV+JcjMm7ok4BlQCOStrfpNM 2yQVECM/gqB9R4OI372Uh0Ob8q/K1DnWn1311m8zKpRNAwuAVkwMdZXA366q40fR2nt8 +kg02BiIzImPF1W3uJpLDlBacsl39TblpS4TdxtPbW5oVShvfF9GEySZukT2XuIVm+KG ppaGdIC0ARz6+iYjOoPQ3rYf6JzbmxSu+M/7nVry3YTqF5A1nug85vTy/hUml6ZvFuwm u/5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wNQkeraNsuw6hFISAboGasHi5jkq9Qw1lk2C7Y7QJNM=; b=K9YjHoc+WM16Zgg5848SXDmMov1LeSRlzR+4H0ajk58yC7qRjP9zgp+2OxQAOmhnm7 mAn/68+kLKjRAYtueGiSp9EoEQhEq/Qlugo5NL3KBPdZWiCrcMQo12ArICgCYLSdXPqa PUQixpf0SxliFOHGtGYApTijL4bLOv5Lb6AQltLM0JNYp382EoatFCiE7NKodvvoqxZ2 KrnGbcfFR4IR7G1Y1x8JxU8MO2a1Znp6ehNDoqfa5dg0GcReTRrsy+uzZaOh8BPI5F1N vKU9LTGL7gX5WXjb5uAhZX4VpOAOA22Z0lz2xiVTjWMnROy08L+gVPH9x9o7MhFkrgwc aedg== X-Gm-Message-State: AO0yUKUAY7Ve2/FsmENXpJ71wIeKIddp3fvQCmi8gtx5F/D3kJ9LanDs DWf8IdpTBJtQe2YzPiaUR5+nMQ== X-Google-Smtp-Source: AK7set/pSiw2S4PkO5YI37ejuDhSsbMg0prresPSYVtL1WK1e+9RTLesegPL247GZtqxm3Qr6U8vqw== X-Received: by 2002:a17:902:ee91:b0:19a:b302:5158 with SMTP id a17-20020a170902ee9100b0019ab3025158mr4053751pld.29.1676973062371; Tue, 21 Feb 2023 01:51:02 -0800 (PST) From: Viresh Kumar To: qemu-devel@nongnu.org, virtio-dev@lists.oasis-open.org, "Michael S. Tsirkin" Cc: Viresh Kumar , Vincent Guittot , =?UTF-8?q?Alex=20Benn=C3=A9e?= , stratos-dev@op-lists.linaro.org, Oleksandr Tyshchenko , xen-devel@lists.xen.org, Andrew Cooper , Juergen Gross , Sebastien Boeuf , Liu Jiang , Mathieu Poirier Subject: [RFC QEMU] docs: vhost-user: Add custom memory mapping support Date: Tue, 21 Feb 2023 15:20:41 +0530 Message-Id: X-Mailer: git-send-email 2.31.1.272.g89b43f80a514 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @linaro.org) X-ZM-MESSAGEID: 1676973101417100001 Content-Type: text/plain; charset="utf-8" The current model of memory mapping at the back-end works fine with Qemu, where a standard call to mmap() for the respective file descriptor, passed from front-end, is generally all we need to do before the front-end can start accessing the guest memory. There are other complex cases though, where we need more information at the backend and need to do more than just an mmap() call. For example, Xen, a type-1 hypervisor, currently supports memory mapping via two different methods, foreign-mapping (via /dev/privcmd) and grant-dev (via /dev/gntdev). In both these cases, the back-end needs to call mmap() followed by an ioctl() (or vice-versa), and need to pass extra information via the ioctl(), like the Xen domain-id of the guest whose memory we are trying to map. Add a new protocol feature, 'VHOST_USER_PROTOCOL_F_CUSTOM_MMAP', which lets the back-end know about the additional memory mapping requirements. When this feature is negotiated, the front-end can send the 'VHOST_USER_CUSTOM_MMAP' message type to provide the additional information to the back-end. Signed-off-by: Viresh Kumar Reviewed-by: Alex Benn=C3=A9e --- docs/interop/vhost-user.rst | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst index 3f18ab424eb0..f2b1d705593a 100644 --- a/docs/interop/vhost-user.rst +++ b/docs/interop/vhost-user.rst @@ -258,6 +258,23 @@ Inflight description =20 :queue size: a 16-bit size of virtqueues =20 +Custom mmap description +^^^^^^^^^^^^^^^^^^^^^^^ + ++-------+-------+ +| flags | value | ++-------+-------+ + +:flags: 64-bit bit field + +- Bit 0 is Xen foreign memory access flag - needs Xen foreign memory mappi= ng. +- Bit 1 is Xen grant memory access flag - needs Xen grant memory mapping. + +:value: a 64-bit hypervisor specific value. + +- For Xen foreign or grant memory access, this is set with guest's xen dom= ain + id. + C structure ----------- =20 @@ -867,6 +884,7 @@ Protocol features #define VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS 14 #define VHOST_USER_PROTOCOL_F_CONFIGURE_MEM_SLOTS 15 #define VHOST_USER_PROTOCOL_F_STATUS 16 + #define VHOST_USER_PROTOCOL_F_CUSTOM_MMAP 17 =20 Front-end message types ----------------------- @@ -1422,6 +1440,20 @@ Front-end message types query the back-end for its device status as defined in the Virtio specification. =20 +``VHOST_USER_CUSTOM_MMAP`` + :id: 41 + :equivalent ioctl: N/A + :request payload: Custom mmap description + :reply payload: N/A + + When the ``VHOST_USER_PROTOCOL_F_CUSTOM_MMAP`` protocol feature has been + successfully negotiated, this message is submitted by the front-end to + notify the back-end of the special memory mapping requirements, that the + back-end needs to take care of, while mapping any memory regions sent + over by the front-end. The front-end must send this message before + any memory-regions are sent to the back-end via ``VHOST_USER_SET_MEM_TAB= LE`` + or ``VHOST_USER_ADD_MEM_REG`` message types. + =20 Back-end message types ---------------------- --=20 2.31.1.272.g89b43f80a514