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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 875F4C433E0 for ; Tue, 16 Feb 2021 15:22:30 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 237A861606 for ; Tue, 16 Feb 2021 15:22:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 237A861606 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=opensynergy.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=j24fLxZp1GsUn2JKCpLmHjNynHen7t/S6psXuF51sjI=; b=BQ58hgs/z/+rRTYcN2HFiWrGG m8Af58Knoluz35taYLOtA97SowVRbTRd/SQ43pcWv1KEwsvNq4LCRtHr2/qGh1sSeb55+2VffyGqM LFJJkU4c/IGxWKXiAgnGQHxebnvOGGIbkVmzlg088bvRFsS1zmopp/TZHKDxzskXWk9Hz4gBLSUB5 dcK+MT5kIsAOpIczZUjbK8JhQGAI0tvCQAwMlg4grEA8cwAXCJ0lcRq8ysWwjYQ/Evr64u5n7yHWQ wmNwl+BcD73k55okmdeCZGFk5VBqKBG9xZwy/3lYmj5pzkr6LThgDcxLQePPgMsD/jT9Zo1v0cx0f YrINqTm7Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lC29Y-0005uF-Vu; Tue, 16 Feb 2021 15:20:41 +0000 Received: from mx1.opensynergy.com ([217.66.60.4]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lC29V-0005tk-Jt for linux-arm-kernel@lists.infradead.org; Tue, 16 Feb 2021 15:20:38 +0000 Received: from SR-MAILGATE-02.opensynergy.com (localhost.localdomain [127.0.0.1]) by mx1.opensynergy.com (Proxmox) with ESMTP id 99E1DA16C5; Tue, 16 Feb 2021 16:12:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opensynergy.com; h=cc:cc:content-transfer-encoding:content-type:content-type :date:from:from:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=srmailgate02; bh=gfwS2vBL5GE1 pZFzdtlvAKvceViE1R9ME9K5AYpHjow=; b=krNAvSBK4YjIzBQc1aKWFnsJuF3d 0r9nKH5VDAmMFbExza9DSKXb0345eZ4rKdITztPYQKsJVCquVEMgXMm3mQ9lpNNM o/DROM/efkR89ZdBGxopM3FY2ZK8YjzEKyA+g65Xtpe1C34o1MlwuhDMO6WgPSU6 wLvEWTufJasdsiCteAfI3lW5i7cGNVvq3dyl0EyN0R6TyGIpW0pNG1d9HTCWzlvF ZceQgK9ZHhQwuFz5sw2wEiQa8VjrzxsCJNFe86zrDYfnvypO/pi5h0ao56mWoZzw Vbn6SBZts6eA9rBCoiTk3MWuufHhlUyggMdYP4E7CFdTN1/wcUTPo6Dv+g== Subject: Re: [PATCH v6] Add virtio SCMI device specification To: Cristian Marussi References: <20210212095920.249768-1-peter.hilber@opensynergy.com> <20210215132029.GD12691@e120937-lin> From: Peter Hilber Autocrypt: addr=peter.hilber@opensynergy.com; prefer-encrypt=mutual; keydata= mQGNBFuyHTIBDAClsxKaykR7WINWbw2hd8SjAU5Ft7Vx2qOyRR3guringPRMDvc5sAQeDPP4 lgFIZS5Ow3Z+0XMb/MtbJt0vQHg4Zi6WQtEysvctmAN4JG08XrO8Kf1Ly86Z0sJOrYTzd9oA JoNqk7/JufMre4NppAMUcJnB1zIDyhKkkGgM1znDvcW/pVkAIKZQ4Be3A9297tl7YjhVLkph kuw3yL8eyj7fk+3vruuEbMafYytozKCSBn5pM0wabiNUlPK39iQzcZd8VMIkh1BszRouInlc 7hjiWjBjGDQ2eAbMww09ETAP1u38PpDolrO8IlTFb7Yy7OlD4lzr8AV+a2CTJhbKrCJznDQS +GPGwLtOqTP5S5OJ0DCqVHdQyKoZMe1sLaZSPLMLx1WYAGN5R8ftCZSBjilVpwJ3lFsqO5cj t5w1/JfNeVBWa4cENt5Z0B2gTuZ4F8j0QAc506uGxWO0wxH1rWNv2LuInSxj8d1yIUu76MqY p92TS3D4t/myerODX3xGnjkAEQEAAbQ7cGV0ZXIuaGlsYmVyQG9wZW5zeW5lcmd5LmNvbSA8 cGV0ZXIuaGlsYmVyQG9wZW5zeW5lcmd5LmNvbT6JAc4EEwEIADgCGwMFCwkIBwIGFQoJCAsC BBYCAwECHgECF4AWIQTj5TCZN1jYfjl5iwQiPT9iQ46MNwUCXXd8PQAKCRAiPT9iQ46MN1PT C/4mgNGlWB1/vsStNH+TGfJKt3eTi1Oxn6Uo0y4sXzZg+CHXYXnrG2OdLgOa/ZdA+O/o1ofU v/nLKki7XH/cGsOtZ6n3Q5+irkLsUI9tcIlxLCZZlgDPqmJO3lu+8Uf2d96udw/5JLiPyhk/ DLtKEnvIOnn2YU9LK80WuJk7CMK4ii/bIipS6WFV6s67YG8HrzMKEwIzScf/7dC/dN221wh0 f3uUMht0A7eVOfEuC/i0//Y+ytuoPcqyT5YsAdvNk4Ns7dmWTJ8MS2t2m55BHQnYh7UBOIqB BkEWLOxbs2zZnC5b/yjg7FOhVxUmSP4wU1Tp/ye+MoVhiUXwzXps5JmOuKahLbIysIpeRNxf B8ndHEjKRl6YglPtqwJ45AF+BFEcblLe4eHk3Gl43jfoBJ43jFUSkge9K7wddB2FpaXrpfwM KupTSWeavVwnjDb+mXfqr4e7C4CX3VoyBQvoGGPpK/93cVZInu5zV/OAxSayXt6NqZECkMBu mg7W7hbcQey0K1BldGVyIEhpbGJlciA8cGV0ZXIuaGlsYmVyQG9wZW5zeW5lcmd5LmNvbT6J Ac4EEwEIADgWIQTj5TCZN1jYfjl5iwQiPT9iQ46MNwUCXjAOKgIbAwULCQgHAgYVCgkICwIE FgIDAQIeAQIXgAAKCRAiPT9iQ46MN6G+C/0R2UCwDr4XdHCjDETK+nGzwEADTkb/bVvnSP8U 1XpoNuFoG0hpx/L9IOacxKCUwL5wGLQ2YjqfmWl5h5nwL/VmisSjtDBU/E9Te825J6avxyXm aSYehTMlBNgGq6gTgGZ2UywbTx51iPtbtqk5IWQSrJfhHgegyapOvDIe3W/L7WdWhpEUAOS2 Rn1pW//rR1RZW0aCuQSi8eT+HKiFid84Kh9x858oNRc9W1bCGjmkFxyhJdxlF7SdwgFahJDm JHfdRyBcpp31WyofNodzNi/39gnrYbxyQmMSMU6Wi5Y9QIGubBB6BN+JlqL0WKgWfyye/6dp R6BrgRLUHBXFegWWLVvQGDli31kXBT0Aey9GQs2sEG3yoYHRAi9/dOip+rJgzqc+k6exP13g ZNBPc5SCrhWk9B/VrZ+frVBhqbu0hYlAnX39cB4szyOJVkGvXPJ6vsewQBv486kIY7IDC+Rk YtC1zNZKSIWSK1+bIXrIBA45rWb6SGq0CgMYdMvUGd25AY0EW7IdMwEMANZOEgW7gpZr0l4M HVvEZomKRgHmKghiKffCyR/cZdB5CWPEsyD0QMkQCQHg0FUQIB/SyS7hV/MOYL47Zb+QUlBo sMGkyyseEBWx0UgxgdMOh88JxAEHs0gQFYjL13DFLX/JfPyUqEnmWHLmvPpwPy2Qp7M1PPYb /KT8YxQEcJ0agxiSSGC+0c6efziPLW1uvGnQpBXhbLRdmUVS9JE390vQLCjIQWQP34e6MnKr ylqPpOeaiVSC9Nvr44f7LDk0X3Hsg3b4kV9TInGcbskXCB9QnKo6lVgXI9Q419WZtI9T/d8n 5Wx54P+iaw4pISqDHi6v+U9YhHACInqJm8S4WhlRIXhXmDVXBjyPvMkxEYp9EGxT5yeu49fN 5oB1SQCf819obhO7GfP2pUx8H3dy96TvKFEQmuh15iXYCxgltrvy9TjUIHj9SbKiaXW1O45t jlDohZJofA0AZ1gU0X8ZVXwqn3vEmrMLDBiko3gdBy7mx2vl+Z1LJyqYKBBvw+pi7wARAQAB iQG2BBgBCAAgAhsMFiEE4+UwmTdY2H45eYsEIj0/YkOOjDcFAl13fD0ACgkQIj0/YkOOjDfF hwv9F6qVRBlMFPmb3dWIs+QcbdgUW9ViGOHNyjCnr+UBE5jc0ERP3IOzcgqavcL5YpuWadfP n4/LyMDhVcl5SQGIdk5oZlRWQRiSpqS+IIU8idu+Ogl/Hdsp4n9S8GiINNwNh5KzWoCNN0Pp crjuMTacJnZur9/ym9tjr+mMvW7Z0k52lnS9L+CRHLKHpVJSnccpTpShQHa335c5YvRC8NN+ Ygj1uZL/98+1GmP1WMZ6nc1LSFDUxR60cxnlbgH7cwBuy8y5DBeCCYiPHKBglVIp5nUFZdLG /HmufQT3f4/GVoDEo2Q7H0lq3KULX1xEwHFeXHw4NXR7mYeX/eftz/9GFMVU29c72NTw8Uih Oy9qJgNo19wroRYKHLz1eWtMVcqS3hbXm0/QcrG9+C9qCPXVxpC/L0YLAtmdvEIyaFtXWRyW 7UQ3us6klHh4XUvSpsQhOgzLHFJ1LpfcupeBYECJQdxgIYyhgFAwRHeLGIPxjlvUmk22C0ua lbekkuPTQs/m Message-ID: Date: Tue, 16 Feb 2021 16:11:42 +0100 MIME-Version: 1.0 In-Reply-To: <20210215132029.GD12691@e120937-lin> Content-Language: en-US X-ClientProxiedBy: SR-MAIL-02.open-synergy.com (10.26.10.22) To SR-MAIL-01.open-synergy.com (10.26.10.21) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210216_102037_865057_4962BA65 X-CRM114-Status: GOOD ( 32.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: virtio-dev@lists.oasis-open.org, Souvik.Chakravarty@arm.com, jean-philippe@linaro.org, virtio-comment@lists.oasis-open.org, Sudeep.Holla@arm.com, alex.bennee@linaro.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 15.02.21 14:20, Cristian Marussi wrote: > Hi Peter, > > just one remark down below. > Hi Cristian, thanks for your comments. Please see my reply inline below. [snip] > > [snip] > >> +The cmdq is used by the driver to send commands to the device. The >> +device replies with responses (not delayed responses) over the cmdq. >> + >> +The eventq is used by the device to send notifications and delayed >> +responses. The eventq only exists if VIRTIO_SCMI_F_P2A_CHANNELS was >> +negotiated. >> + >> +\subsection{Feature bits}\label{sec:Device Types / SCMI Device / Feature bits} >> + >> +\begin{description} >> +\item[VIRTIO_SCMI_F_P2A_CHANNELS (0)] Device implements some SCMI >> +notifications, or delayed responses. >> +\item[VIRTIO_SCMI_F_SHARED_MEMORY (1)] Device implements any SCMI >> +statistics shared memory region. >> +\end{description} >> + >> +VIRTIO_SCMI_F_P2A_CHANNELS is used to determine the existence of the >> +eventq. The eventq is required for SCMI notifications and delayed >> +responses. >> + >> +VIRTIO_SCMI_F_SHARED_MEMORY is used to determine whether the device >> +provides any SCMI statistics shared memory region. SCMI statistics >> +shared memory regions are defined by some SCMI protocols. >> + >> +The SCMI protocols provide the PROTOCOL_MESSAGE_ATTRIBUTES commands to >> +inquire about the particular SCMI notifications and delayed responses >> +implemented by the device. The SCMI protocols provide additional >> +commands to detect other features implemented by the device. >> + >> +\devicenormative{\subsubsection}{Feature bits}{Device Types / SCMI Device / Feature bits} >> + >> +The device MUST offer VIRTIO_SCMI_F_P2A_CHANNELS if the device can >> +implement at least one SCMI notification, or delayed response. >> + >> +The device MUST offer VIRTIO_SCMI_F_SHARED_MEMORY if the device can >> +implement at least one SCMI statistics shared memory region. >> + >> +\subsection{Device configuration layout}\label{sec:Device Types / SCMI Device / Device configuration layout} >> + >> +There is no configuration data for the device. >> + > > I could be missing something here, so I apologize upfront if this has > already been discussed elsewhere, but AFAIU the fact that no device > configuration is exposed here (like a device ID) implies that SCMI devices > are not "identifiable" from within the VirtIO subsystem, so not > distinguishable in other words. > > At the same time in the companion RFC driver series it has been already > also ruled out (as of now at least) by the DT maintainer the possibility > to establish a link at the DT level between an SCMI virtio-mmio device > definition and the SCMI related DT descriptions (because, AFAIU, it's not > something needed by any of all the other existent VirtIO devices that are > indeed usually somehow 'identifiable') > > These 2 things combined together rule out any future possibility to have > multiple SCMI devices defined on a system (at least not identifiable/usable) > in order to support multiple distinct transport channels against the same > platform (or, less desirable, multiple platforms), and in fact the SCMI virtio > transport RFC driver as of now states upfront that only one device/once channel > configuration is supported. > > Even if not the norm probably, I would say that could be useful to leave > open for the future the possibility to redirect some protocols down through > a specific distinct VirtIO channel (other than the main one), at least for > debug/testing purposes if not to support multiple platform residing in > distinct VMs. > Another use case could be separating the transport channel used by some > possibly chatty protocol like Sensors (possibly flooding the system with > lots of notifications) from other SCMI protocols, that could benefit from > having a dedicated quieter virtio-mmio SCMI device channel (with dedicated > IRQs and friends...) > > Beside that, also the general fact that this SCMI transport does not support > multiple channels is a bit at odd with all the other SCMI transports > (like mailbox/svc that, it's to be said, are indeed based instead on > shared memory) > > So, what I'm saying here is if it's not the case of having some sort of > device_id in the configuration space, so that a platform could expose, > if it wants, multiple identifiable devices and the agents could pick the > device they want and associate with a specific protocol. > (via some DT transport reference to the desired SCMI device_id to use, > similarly to what's possible with shared mems transports) > > But, as said, it could have been already discussed and ruled out so feel > free to ignore this and point me at the related pre-existing discussion > threads. > This has not been discussed on the mailing list so far. I think both features, multiple devices and dedicated transport channels/virtqueues (similar to the SCMI SHM transport), do make sense, but we at OpenSynergy do so far not have a use case which requires them. The multiple devices feature would be straightforward to add in my understanding (just add an `id' device configuration field). From what you wrote I understand the dedicated transport channels could just mimic the SCMI SHM channels scheme from the Linux kernel, with optional per-protocol channels. Virtio is extensible through feature bits in a backwards-compatible way, so I think both features could also be introduced as extensions once there is a need for them. (This is actually done very often for other virtio devices.) I guess it would even be very straightforward to backport these features to older Linux kernels then. Would this option of introducing feature bits in the future address your concerns? Best regards, Peter > Thanks > > Cristian > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-comment-return-1720-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: References: <20210212095920.249768-1-peter.hilber@opensynergy.com> <20210215132029.GD12691@e120937-lin> From: Peter Hilber Message-ID: Date: Tue, 16 Feb 2021 16:11:42 +0100 MIME-Version: 1.0 In-Reply-To: <20210215132029.GD12691@e120937-lin> Subject: [virtio-comment] Re: [PATCH v6] Add virtio SCMI device specification Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit To: Cristian Marussi Cc: virtio-comment@lists.oasis-open.org, linux-arm-kernel@lists.infradead.org, Souvik.Chakravarty@arm.com, Sudeep.Holla@arm.com, virtio-dev@lists.oasis-open.org, alex.bennee@linaro.org, jean-philippe@linaro.org List-ID: On 15.02.21 14:20, Cristian Marussi wrote: > Hi Peter, > > just one remark down below. > Hi Cristian, thanks for your comments. Please see my reply inline below. [snip] > > [snip] > >> +The cmdq is used by the driver to send commands to the device. The >> +device replies with responses (not delayed responses) over the cmdq. >> + >> +The eventq is used by the device to send notifications and delayed >> +responses. The eventq only exists if VIRTIO_SCMI_F_P2A_CHANNELS was >> +negotiated. >> + >> +\subsection{Feature bits}\label{sec:Device Types / SCMI Device / Feature bits} >> + >> +\begin{description} >> +\item[VIRTIO_SCMI_F_P2A_CHANNELS (0)] Device implements some SCMI >> +notifications, or delayed responses. >> +\item[VIRTIO_SCMI_F_SHARED_MEMORY (1)] Device implements any SCMI >> +statistics shared memory region. >> +\end{description} >> + >> +VIRTIO_SCMI_F_P2A_CHANNELS is used to determine the existence of the >> +eventq. The eventq is required for SCMI notifications and delayed >> +responses. >> + >> +VIRTIO_SCMI_F_SHARED_MEMORY is used to determine whether the device >> +provides any SCMI statistics shared memory region. SCMI statistics >> +shared memory regions are defined by some SCMI protocols. >> + >> +The SCMI protocols provide the PROTOCOL_MESSAGE_ATTRIBUTES commands to >> +inquire about the particular SCMI notifications and delayed responses >> +implemented by the device. The SCMI protocols provide additional >> +commands to detect other features implemented by the device. >> + >> +\devicenormative{\subsubsection}{Feature bits}{Device Types / SCMI Device / Feature bits} >> + >> +The device MUST offer VIRTIO_SCMI_F_P2A_CHANNELS if the device can >> +implement at least one SCMI notification, or delayed response. >> + >> +The device MUST offer VIRTIO_SCMI_F_SHARED_MEMORY if the device can >> +implement at least one SCMI statistics shared memory region. >> + >> +\subsection{Device configuration layout}\label{sec:Device Types / SCMI Device / Device configuration layout} >> + >> +There is no configuration data for the device. >> + > > I could be missing something here, so I apologize upfront if this has > already been discussed elsewhere, but AFAIU the fact that no device > configuration is exposed here (like a device ID) implies that SCMI devices > are not "identifiable" from within the VirtIO subsystem, so not > distinguishable in other words. > > At the same time in the companion RFC driver series it has been already > also ruled out (as of now at least) by the DT maintainer the possibility > to establish a link at the DT level between an SCMI virtio-mmio device > definition and the SCMI related DT descriptions (because, AFAIU, it's not > something needed by any of all the other existent VirtIO devices that are > indeed usually somehow 'identifiable') > > These 2 things combined together rule out any future possibility to have > multiple SCMI devices defined on a system (at least not identifiable/usable) > in order to support multiple distinct transport channels against the same > platform (or, less desirable, multiple platforms), and in fact the SCMI virtio > transport RFC driver as of now states upfront that only one device/once channel > configuration is supported. > > Even if not the norm probably, I would say that could be useful to leave > open for the future the possibility to redirect some protocols down through > a specific distinct VirtIO channel (other than the main one), at least for > debug/testing purposes if not to support multiple platform residing in > distinct VMs. > Another use case could be separating the transport channel used by some > possibly chatty protocol like Sensors (possibly flooding the system with > lots of notifications) from other SCMI protocols, that could benefit from > having a dedicated quieter virtio-mmio SCMI device channel (with dedicated > IRQs and friends...) > > Beside that, also the general fact that this SCMI transport does not support > multiple channels is a bit at odd with all the other SCMI transports > (like mailbox/svc that, it's to be said, are indeed based instead on > shared memory) > > So, what I'm saying here is if it's not the case of having some sort of > device_id in the configuration space, so that a platform could expose, > if it wants, multiple identifiable devices and the agents could pick the > device they want and associate with a specific protocol. > (via some DT transport reference to the desired SCMI device_id to use, > similarly to what's possible with shared mems transports) > > But, as said, it could have been already discussed and ruled out so feel > free to ignore this and point me at the related pre-existing discussion > threads. > This has not been discussed on the mailing list so far. I think both features, multiple devices and dedicated transport channels/virtqueues (similar to the SCMI SHM transport), do make sense, but we at OpenSynergy do so far not have a use case which requires them. The multiple devices feature would be straightforward to add in my understanding (just add an `id' device configuration field). From what you wrote I understand the dedicated transport channels could just mimic the SCMI SHM channels scheme from the Linux kernel, with optional per-protocol channels. Virtio is extensible through feature bits in a backwards-compatible way, so I think both features could also be introduced as extensions once there is a need for them. (This is actually done very often for other virtio devices.) I guess it would even be very straightforward to backport these features to older Linux kernels then. Would this option of introducing feature bits in the future address your concerns? Best regards, Peter > Thanks > > Cristian > > This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/