From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from ws5-mx01.kavi.com (ws5-mx01.kavi.com [34.193.7.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2FC2BC001B0 for ; Fri, 7 Jul 2023 08:11:24 +0000 (UTC) Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by ws5-mx01.kavi.com (Postfix) with ESMTP id 6ED6A2AED9 for ; Fri, 7 Jul 2023 08:11:23 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 502BB9867F9 for ; Fri, 7 Jul 2023 08:11:23 +0000 (UTC) Received: from host09.ws5.connectedcommunity.org (host09.ws5.connectedcommunity.org [10.110.1.97]) by lists.oasis-open.org (Postfix) with QMQP id 39F73984091; Fri, 7 Jul 2023 08:11:23 +0000 (UTC) Mailing-List: contact virtio-dev-help@lists.oasis-open.org; run by ezmlm List-ID: Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 261739867EB for ; Fri, 7 Jul 2023 08:11:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688717480; x=1691309480; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:user-agent:references:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=tZSiuHkgL0yIE4O7HLzt7OeU1T4BdYuO8GxB/QwP7IE=; b=CQaNFT1QL3zycWZyyux9BZ0131iIjqfHG9gRs6pGkiujTF+hIntvGQn6fYbXQvzqiX RXrVPKEiXep7yMXdSCpu+uhMIbQ+9fYbdXXX3GP7APXHxXbYPJzlNYy5sqpGIfLU9Ak1 hXF67vxvrGmxPX15xm48Ev8uLAMjWUiTIag3Wrv4yT/t26C9bVG45qmZeOFWR5Pjtaxj egINpIAQoYt91BpMptgBBlLEdfAfrOGzZ+fzl6Yx2T4m/I7V6mSg1SzIdMiH7JxHcSCF gNSjXMrui2QgCWnylTZMe4Kefn8eQHhhE4aSXnaiC3bXy+CA+KD6q5wgZ6xoQN6cfV+f +kYA== X-Gm-Message-State: ABy/qLbKt1otkAU1voMtfSyGbsCRTnlCUlFXeYYAJLM4j8Ci1Y2BZWdj fCbpaOo0MWsLN6D1KsPtl4WQnQ== X-Google-Smtp-Source: APBJJlELgNlFsG5To0sX/neKfbROvRH2npY/Vu4w+FYIb8dQp2oL4hHsoTptBpUvIg2XpjB0R41XKQ== X-Received: by 2002:adf:f809:0:b0:314:421f:532f with SMTP id s9-20020adff809000000b00314421f532fmr3564042wrp.44.1688717480600; Fri, 07 Jul 2023 01:11:20 -0700 (PDT) References: <20230704123600.1808604-1-alex.bennee@linaro.org> <20230706124347-mutt-send-email-mst@kernel.org> User-agent: mu4e 1.11.9; emacs 29.0.92 From: Alex =?utf-8?Q?Benn=C3=A9e?= To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, virtio-dev@lists.oasis-open.org, slp@redhat.com, marcandre.lureau@redhat.com, stefanha@redhat.com, viresh.kumar@linaro.org, sgarzare@redhat.com, takahiro.akashi@linaro.org, erik.schilling@linaro.org, manos.pitsidianakis@linaro.org, mathieu.poirier@linaro.org Date: Fri, 07 Jul 2023 08:58:00 +0100 In-reply-to: <20230706124347-mutt-send-email-mst@kernel.org> Message-ID: <87ilawdtug.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [virtio-dev] Re: [RFC PATCH] docs/interop: define STANDALONE protocol feature for vhost-user "Michael S. Tsirkin" writes: > On Tue, Jul 04, 2023 at 01:36:00PM +0100, Alex Benn=C3=A9e wrote: >> Currently QEMU has to know some details about the back-end to be able >> to setup the guest. While various parts of the setup can be delegated >> to the backend (for example config handling) this is a very piecemeal >> approach. > >> This patch suggests a new feature flag (VHOST_USER_PROTOCOL_F_STANDALONE) >> which the back-end can advertise which allows a probe message to be >> sent to get all the details QEMU needs to know in one message. > > The reason we do piecemeal is that these existing pieces can be reused > as others evolve or fall by wayside. Sure I have no objection in principle but we then turn code like: if (dev->protocol_features & (1ULL << VHOST_USER_PROTOCOL_F_STANDAL= ONE)) { err =3D vhost_user_get_backend_specs(dev, errp); if (err < 0) { error_setg_errno(errp, EPROTO, "vhost_get_backend_specs fai= led"); return -EPROTO; } } to if (dev->protocol_features & (1ULL << VHOST_USER_PROTOCOL_F_ID) && dev->protocol_features & (1ULL << VHOST_USER_PROTOCOL_F_CFGSZ) = && dev->protocol_features & (1ULL << VHOST_USER_PROTOCOL_F_MINVQ) = && dev->protocol_features & (1ULL << VHOST_USER_PROTOCOL_F_MAXVQ) ) { err =3D vhost_user_get_virtio_id(dev, errp); if (err < 0) { error_setg_errno(errp, EPROTO, "vhost_get_backend_id failed= "); return -EPROTO; } err =3D vhost_user_get_virtio_cfgsz(dev, errp); if (err < 0) { error_setg_errno(errp, EPROTO, "vhost_get_backend_cfgsz fai= led"); return -EPROTO; } err =3D vhost_user_get_virtio_minvq(dev, errp); if (err < 0) { error_setg_errno(errp, EPROTO, "vhost_get_backend_minvq fai= led"); return -EPROTO; } err =3D vhost_user_get_virtio_maxvq(dev, errp); if (err < 0) { error_setg_errno(errp, EPROTO, "vhost_get_backend_maxvq fai= led"); return -EPROTO; } dev->specs.valid =3D true; } for little gain IMHO. > For example, I can think of instances where you want to connect > specifically to e.g. networking backend, and specify it > on command line. Reasons could be many, e.g. for debugging, > or to prevent connecting to wrong device on wrong channel > (kind of like type safety). I don't quite follow what you are trying to say here. > What is the reason to have 1 message? startup latency? > How about we allow pipelining several messages then? > Will be easier. I'm not overly worried about performance because this is all at start-up. I am worried about excessive complexity though. We already have quite a lot of interacting protocol messages. > > >>=20 >> Signed-off-by: Alex Benn=C3=A9e >>=20 >> --- >> Initial RFC for discussion. I intend to prototype this work with QEMU >> and one of the rust-vmm vhost-user daemons. >> --- >> docs/interop/vhost-user.rst | 37 +++++++++++++++++++++++++++++++++++++ >> hw/virtio/vhost-user.c | 8 ++++++++ >> 2 files changed, 45 insertions(+) >>=20 >> diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst >> index 5a070adbc1..85b1b1583a 100644 >> --- a/docs/interop/vhost-user.rst >> +++ b/docs/interop/vhost-user.rst >> @@ -275,6 +275,21 @@ Inflight description >>=20=20 >> :queue size: a 16-bit size of virtqueues >>=20=20 >> +Backend specifications >> +^^^^^^^^^^^^^^^^^^^^^^ >> + >> ++-----------+-------------+------------+------------+ >> +| device id | config size | min_vqs | max_vqs | >> ++-----------+-------------+------------+------------+ >> + >> +:device id: a 32-bit value holding the VirtIO device ID >> + >> +:config size: a 32-bit value holding the config size (see ``VHOST_USER_= GET_CONFIG``) >> + >> +:min_vqs: a 32-bit value holding the minimum number of vqs supported >> + >> +:max_vqs: a 32-bit value holding the maximum number of vqs supported, m= ust be >=3D min_vqs >> + > > looks like a weird set of info. It's basically the information you need for -device vhost-user-device to start-up (and what is essentially the information set by the stubs as they start-up). > why would we want # of vqs and not their sizes? I thought the vring's themselves where allocated by the driver. We only need to the number of vqs so we can allocate the tracking structures. > why config size but not config itself? We already have GET_CONFIG and SET_CONFIG but without knowing the size of the config space we can't properly set it up. --=20 Alex Benn=C3=A9e Virtualisation Tech Lead @ Linaro --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 026BFEB64DA for ; Fri, 7 Jul 2023 08:11:58 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHgYp-0002eU-3p; Fri, 07 Jul 2023 04:11:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHgYn-0002dp-Ni for qemu-devel@nongnu.org; Fri, 07 Jul 2023 04:11:25 -0400 Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qHgYk-0006yZ-2U for qemu-devel@nongnu.org; Fri, 07 Jul 2023 04:11:23 -0400 Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-313f1085ac2so1557049f8f.1 for ; Fri, 07 Jul 2023 01:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1688717480; x=1691309480; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:user-agent:references:from:to:cc:subject:date :message-id:reply-to; bh=tZSiuHkgL0yIE4O7HLzt7OeU1T4BdYuO8GxB/QwP7IE=; b=SgZzwzTmfrpJW45AQv4cZhlMtl0qUEkPbDYQ+zWBeemCu186kHjR5GziCLwNO/XVox 8YowywwCKDz03LxFhgWqDriMP/EtGWsTDykREIXsIKoVLhpZmDUHDYSKMZt1sQvA2HoC zPkSbHeZoTVDmjM57QfaOXrep2/wgTnYnvPTpjXR3+hNti06z5YMuhivr+kXrGZ9FMII oKfRdBId1xzLwtr5pHC/SfEo40Faby7XiMYUFqEA7afDoANnnHQXQ9Y//sijqEqQpiE+ KBqZN1wIMyLWcPmWudi/MJH+ShU4LfWLx+lMN1MTgxIZOAIK++azU7QObluJDM5jWRs1 srmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688717480; x=1691309480; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:user-agent:references:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=tZSiuHkgL0yIE4O7HLzt7OeU1T4BdYuO8GxB/QwP7IE=; b=mGCLD0ZNjISSEJoUEfZ//mA24nb9zoSMmIjnWFmnKoWBrQbL31dpQdiC6BlJuHmbka bLhvSRDj7sjQSwp05j45GmNpOgoGQ52QM36F5IDEz27yhskSG5rHDlXmy9A9JrWPrOTw QHw+b+4NZ0QHpkpMs97cyYxK6SGZD0N0e3AfqVHzay4URP8w2f7ZKZpE5UmgvOTKlOCg 1LWhTlgPX3XGeFU7wTspF3EUT1Y/Xh/aiXLqr8SMfBfc+v/kujvRo9gskSHXyk2K+V0d lYBGJR6aONupk/00SRfB+3QJWBAA6SQzl1M44YUTeQLPebYGNPcXn1GgyGjo3M4t2bn7 AI/g== X-Gm-Message-State: ABy/qLYEGwF88esDz+s7iK2ReCSLIM7SOlSCOH1/4G3XyAclBCRpJKDf ALz70Kk5BM83h/yGbwD6r8d9AA== X-Google-Smtp-Source: APBJJlELgNlFsG5To0sX/neKfbROvRH2npY/Vu4w+FYIb8dQp2oL4hHsoTptBpUvIg2XpjB0R41XKQ== X-Received: by 2002:adf:f809:0:b0:314:421f:532f with SMTP id s9-20020adff809000000b00314421f532fmr3564042wrp.44.1688717480600; Fri, 07 Jul 2023 01:11:20 -0700 (PDT) Received: from zen.linaroharston ([85.9.250.243]) by smtp.gmail.com with ESMTPSA id z18-20020a5d6552000000b0030fd03e3d25sm3801870wrv.75.2023.07.07.01.11.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Jul 2023 01:11:20 -0700 (PDT) Received: from zen (localhost [127.0.0.1]) by zen.linaroharston (Postfix) with ESMTP id CA9481FFBB; Fri, 7 Jul 2023 09:11:19 +0100 (BST) References: <20230704123600.1808604-1-alex.bennee@linaro.org> <20230706124347-mutt-send-email-mst@kernel.org> User-agent: mu4e 1.11.9; emacs 29.0.92 From: Alex =?utf-8?Q?Benn=C3=A9e?= To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, virtio-dev@lists.oasis-open.org, slp@redhat.com, marcandre.lureau@redhat.com, stefanha@redhat.com, viresh.kumar@linaro.org, sgarzare@redhat.com, takahiro.akashi@linaro.org, erik.schilling@linaro.org, manos.pitsidianakis@linaro.org, mathieu.poirier@linaro.org Subject: Re: [RFC PATCH] docs/interop: define STANDALONE protocol feature for vhost-user Date: Fri, 07 Jul 2023 08:58:00 +0100 In-reply-to: <20230706124347-mutt-send-email-mst@kernel.org> Message-ID: <87ilawdtug.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::436; envelope-from=alex.bennee@linaro.org; helo=mail-wr1-x436.google.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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org "Michael S. Tsirkin" writes: > On Tue, Jul 04, 2023 at 01:36:00PM +0100, Alex Benn=C3=A9e wrote: >> Currently QEMU has to know some details about the back-end to be able >> to setup the guest. While various parts of the setup can be delegated >> to the backend (for example config handling) this is a very piecemeal >> approach. > >> This patch suggests a new feature flag (VHOST_USER_PROTOCOL_F_STANDALONE) >> which the back-end can advertise which allows a probe message to be >> sent to get all the details QEMU needs to know in one message. > > The reason we do piecemeal is that these existing pieces can be reused > as others evolve or fall by wayside. Sure I have no objection in principle but we then turn code like: if (dev->protocol_features & (1ULL << VHOST_USER_PROTOCOL_F_STANDAL= ONE)) { err =3D vhost_user_get_backend_specs(dev, errp); if (err < 0) { error_setg_errno(errp, EPROTO, "vhost_get_backend_specs fai= led"); return -EPROTO; } } to if (dev->protocol_features & (1ULL << VHOST_USER_PROTOCOL_F_ID) && dev->protocol_features & (1ULL << VHOST_USER_PROTOCOL_F_CFGSZ) = && dev->protocol_features & (1ULL << VHOST_USER_PROTOCOL_F_MINVQ) = && dev->protocol_features & (1ULL << VHOST_USER_PROTOCOL_F_MAXVQ) ) { err =3D vhost_user_get_virtio_id(dev, errp); if (err < 0) { error_setg_errno(errp, EPROTO, "vhost_get_backend_id failed= "); return -EPROTO; } err =3D vhost_user_get_virtio_cfgsz(dev, errp); if (err < 0) { error_setg_errno(errp, EPROTO, "vhost_get_backend_cfgsz fai= led"); return -EPROTO; } err =3D vhost_user_get_virtio_minvq(dev, errp); if (err < 0) { error_setg_errno(errp, EPROTO, "vhost_get_backend_minvq fai= led"); return -EPROTO; } err =3D vhost_user_get_virtio_maxvq(dev, errp); if (err < 0) { error_setg_errno(errp, EPROTO, "vhost_get_backend_maxvq fai= led"); return -EPROTO; } dev->specs.valid =3D true; } for little gain IMHO. > For example, I can think of instances where you want to connect > specifically to e.g. networking backend, and specify it > on command line. Reasons could be many, e.g. for debugging, > or to prevent connecting to wrong device on wrong channel > (kind of like type safety). I don't quite follow what you are trying to say here. > What is the reason to have 1 message? startup latency? > How about we allow pipelining several messages then? > Will be easier. I'm not overly worried about performance because this is all at start-up. I am worried about excessive complexity though. We already have quite a lot of interacting protocol messages. > > >>=20 >> Signed-off-by: Alex Benn=C3=A9e >>=20 >> --- >> Initial RFC for discussion. I intend to prototype this work with QEMU >> and one of the rust-vmm vhost-user daemons. >> --- >> docs/interop/vhost-user.rst | 37 +++++++++++++++++++++++++++++++++++++ >> hw/virtio/vhost-user.c | 8 ++++++++ >> 2 files changed, 45 insertions(+) >>=20 >> diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst >> index 5a070adbc1..85b1b1583a 100644 >> --- a/docs/interop/vhost-user.rst >> +++ b/docs/interop/vhost-user.rst >> @@ -275,6 +275,21 @@ Inflight description >>=20=20 >> :queue size: a 16-bit size of virtqueues >>=20=20 >> +Backend specifications >> +^^^^^^^^^^^^^^^^^^^^^^ >> + >> ++-----------+-------------+------------+------------+ >> +| device id | config size | min_vqs | max_vqs | >> ++-----------+-------------+------------+------------+ >> + >> +:device id: a 32-bit value holding the VirtIO device ID >> + >> +:config size: a 32-bit value holding the config size (see ``VHOST_USER_= GET_CONFIG``) >> + >> +:min_vqs: a 32-bit value holding the minimum number of vqs supported >> + >> +:max_vqs: a 32-bit value holding the maximum number of vqs supported, m= ust be >=3D min_vqs >> + > > looks like a weird set of info. It's basically the information you need for -device vhost-user-device to start-up (and what is essentially the information set by the stubs as they start-up). > why would we want # of vqs and not their sizes? I thought the vring's themselves where allocated by the driver. We only need to the number of vqs so we can allocate the tracking structures. > why config size but not config itself? We already have GET_CONFIG and SET_CONFIG but without knowing the size of the config space we can't properly set it up. --=20 Alex Benn=C3=A9e Virtualisation Tech Lead @ Linaro