From patchwork Tue Jun 28 11:03:44 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Pinto X-Patchwork-Id: 9202903 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 9C2A96074E for ; Tue, 28 Jun 2016 11:07:58 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8BC5C28600 for ; Tue, 28 Jun 2016 11:07:58 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7FB9828606; Tue, 28 Jun 2016 11:07:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id B49DA28600 for ; Tue, 28 Jun 2016 11:07:57 +0000 (UTC) Received: from localhost ([::1]:35880 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHqs0-0002zu-Rw for patchwork-qemu-devel@patchwork.kernel.org; Tue, 28 Jun 2016 07:07:56 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHqqW-0001cK-Uw for qemu-devel@nongnu.org; Tue, 28 Jun 2016 07:06:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHqqT-0007T8-IK for qemu-devel@nongnu.org; Tue, 28 Jun 2016 07:06:23 -0400 Received: from mail-wm0-x243.google.com ([2a00:1450:400c:c09::243]:34204) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHqqT-0007Sq-7Y for qemu-devel@nongnu.org; Tue, 28 Jun 2016 07:06:21 -0400 Received: by mail-wm0-x243.google.com with SMTP id 187so4975292wmz.1 for ; Tue, 28 Jun 2016 04:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualopensystems-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=ZkGvAGbpgHyA2VU1bR4w44dSC7nI9firFyfbs/6nin8=; b=XA+OKNmWz+LAaUiwVFyIcwRgxlfMr2NsI7xohF9a7CVWr0HK0aR/7HriAE11ASjhqC AqjP2YIm4Rc7JZhhA07eaW7IoC1CX88q3kqmxVUuWnrKKFNp3Ay8HbxsJh6R3vE5Hdo5 oxIVcQWbUyPDmpnu5+MRoQHzq2lcVEloDKH1RpEReJYjgNXxLUaTTsXwH8xY9/MQ//G+ IZ3dCQsUasNV/IpJnt7wPG4Wd2hHcF+NR3wTbppFHY9LZcx1iMJFk852MzxwS7FSGuuO AaHT3Ion27e+zhTvIy3CXsBO+NaHNv1A2hnt/EK9HHeCD30vuIh2iOisr5iLv2FDn70s rx6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=ZkGvAGbpgHyA2VU1bR4w44dSC7nI9firFyfbs/6nin8=; b=DYP0vAlQXypdsRh+w+9z+gzdTGr6rfXcBRG480ZRk1otddKA7KVplDUU9FM3rvJ1yn lBBW5vvvgMLlCUcJxyEEFYH7HSzbGRP12Vj+P4yrW8SDs96201eCvQZLVLIj5fNz+yLh wWqHSs8WsJX+JUxr0P/FgrJdrrAiyrLHpP6E8Zg6onpCNdYNggg3V78YJjvdByfco2bg jwnrrZY/X7tmFo0Kq6+a1jUcSJr5Lt9mf4ubvyleZ+8sIUSG1DbXBsaMirVhrdjva7Lr 7RyucapLMUekxacGPpRDch/tfJPtmjyaB/YSIkR9fC8bgWpakBsRUuEQe9FKfeJ3AiRY FNOw== X-Gm-Message-State: ALyK8tKn+3lQ7lI4VWjENXjgRly7Hyl2n1YeONExqYbpIFm3xTeA02mBK1r6DyMZj67Ojw== X-Received: by 10.194.96.208 with SMTP id du16mr2842920wjb.0.1467111980513; Tue, 28 Jun 2016 04:06:20 -0700 (PDT) Received: from localhost.localdomain ([151.53.69.157]) by smtp.googlemail.com with ESMTPSA id l1sm13596162wjy.17.2016.06.28.04.06.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Jun 2016 04:06:19 -0700 (PDT) From: Christian Pinto To: virtio-dev@lists.oasis-open.org Date: Tue, 28 Jun 2016 13:03:44 +0200 Message-Id: <1467111824-11548-3-git-send-email-c.pinto@virtualopensystems.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1467111824-11548-1-git-send-email-c.pinto@virtualopensystems.com> References: <1467111824-11548-1-git-send-email-c.pinto@virtualopensystems.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::243 Subject: [Qemu-devel] [virtio-dev][RFC v2 2/2] virtio-sdm: new device specification X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: b.reynal@virtualopensystems.com, Claudio.Fontana@huawei.com, qemu-devel@nongnu.org, Christian Pinto , stefanha@redhat.com, cornelia.huck@de.ibm.com, Jani.Kokkonen@huawei.com, tech@virtualopensystems.com Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP This patch adds the specification of the Signal Dristribution Module virtio device to the current virtio specification document. Signed-off-by: Christian Pinto Signed-off-by: Baptiste Reynal --- v1 -> v2: - Fixed some typos - Removed dependencies from QEMU - Added explanation on how SDM can be used in AMP systems - Explained semantics of payload field in SDMSignalData struct --- content.tex | 2 + virtio-sdm.tex | 128 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 130 insertions(+) create mode 100644 virtio-sdm.tex diff --git a/content.tex b/content.tex index 3317916..7fcf779 100644 --- a/content.tex +++ b/content.tex @@ -5643,6 +5643,8 @@ descriptor for the \field{sense_len}, \field{residual}, \field{status_qualifier}, \field{status}, \field{response} and \field{sense} fields. +\input{virtio-sdm.tex} + \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits} Currently there are three device-independent feature bits defined: diff --git a/virtio-sdm.tex b/virtio-sdm.tex new file mode 100644 index 0000000..76b0a7b --- /dev/null +++ b/virtio-sdm.tex @@ -0,0 +1,128 @@ +\section{Signal Distribution Module}\label{sec:Device Types / SDM Device} + +The virtio Signal Distribution Module is meant to enable Inter Processor signal +exchange. +An example are Inter Processor Interrupts used in AMP systems, for the +processors involved to notify the presence of new data in the communication +queues. +In AMP systems signals are used for various purposes, an example are remoteproc +or RPMSG. In the former signals are used by a master processor to trigger +the boot of a slave processor. While the latter, RPMSG, uses virtio queues as a +message exchange medium between processors. In this case the SDM can be used to +generate the interrupt associated to the kick of a virtio queue. + +\subsection{Device ID}\label{sec:Device Types / SDM Device / Device ID} + +21 + +\subsection{Virtqueues}\label{sec:Device Types / SDM Device / Virtqueues} + +\begin{description} +\item[0] hg_vq +\item[1] gh_vq +\end{description} + +Queue 0 is used for device-to-driver communication (i.e., notification of a +signal), while queue 1 for driver-to-device communication. + +\subsection{Feature bits}\label{sec:Device Types / SDM Device / Feature bits} + +None. + +\subsection{Device configuration layout}\label{sec:Device Types / SDM Device / +Device configuration layout} + +The device configuration is composed by three fields: \texttt{master}, +\texttt{max_slaves} and \texttt{current_slaves}. + +\begin{lstlisting} +struct virtio_sdm_config { + u8 master; + u16 max_slaves; + u16 current_slaves; +}; +\end{lstlisting} + +The SDM device can be instantiated either as a master or as a slave. The master +slave behavior is meant on purpose to reflect the AMP like type of communication +where a master processor controls one or more slave processors. +A master SDM instance can send a signal to any of the slaves instances, +while slaves can only signal the master. + +The \texttt{master} field of the configuration space is meant to be read by the +driver to figure out whether a specific instance is a master or a slave. +The \texttt{max_slaves} field contains the maximum number of slaves supported by +the SDM device. A notification change is sent to the driver each time the value +of \texttt{max_slaves} is changed from the device side. +Finally, the \texttt{current_slaves} field contains the actual number of slaves +registered to the master SDM. This field is a read only field. + +\subsection{Device Initialization}\label{sec:Device Types / SDM Device / +evice Initialization} + +During initialization the \texttt{hg_vq} and \texttt{gh_vq} are identified and +the device is immediately operational. A master driver instance can access the +number of slaves registered at any time by reading the configuration space of +the device. + +During the initialization phase the device connects also to the communication +channel. It has to be noted that the behavior of the device is +independent from the communication channel used, that is a detail of each +specific implementation of the SDM device. + +\subsection{Device Operation}\label{sec:Device Types / SDM Device / Device +peration} + +The SDM device handles signals coming from the two following sources: + +\begin{enumerate} +\item The local processor to which the device is attached to. +\item The communication channel connecting to other slaves/master. +\end{enumerate} + +The first case is verified when the processor attached to the SDM device wants +to send a signal to a second SDM device instance. +The second case is instead when an SDM device instance receives a signal from +another SDM device, to be forwarded to the local processor. +It is important to note that due to the master/slave behavior, slaves cannot +signal among themselves but only with the master SDM instance. + +In both cases, before sending over the communication channel, the signal is +packed in the \texttt{SDMSignalData} data structure. + +\begin{lstlisting} +enum sdm_signal_type { + SDM_IRQ, + SDM_BOOT, +}; + +struct SDMSignalData { + uint32_t type; + uint32_t slave; + uint32_t payload[2]; +}; +\end{lstlisting} + +The \texttt{type} field indicates the type of signal to be sent to the +destination SDM. The current implementation supports two signal types. +The \texttt{SDM_IRQ} signal is used to send an inter processor interrupt, while +the \texttt{SDM_BOOT} signal is sent to trigger the boot of the destination +processor. The boot signal is meant to be used in an AMP like scenario where a +master processor boots one or more slave processors (e.g., via remoteproc). +The \texttt{slave} field contains the id of the SDM instance destination of the +signal. Id 0 is reserved for the master, from 1 onwards for the slaves. +This means that the \texttt{slave} field will always contain 0 when the source +of the signal is a slave SDM instance, while the actual id of the slave in case +of a master. +The \texttt{payload} is used to pass extra accompanying information with the +signal. +The semantics of the payload field depends on the signal itself. In case of +\texttt{SDM_IRQ} signal, the payload field is ignored since interrupts do not +need any extra information to be handled. In the case of \texttt{SDM_BOOT} +signal the payload contains the boot address of the slave processor, to be used +at the destination to initialize the program counter register before the actual +boot process is started. + + +The \texttt{SDMSignalData} structure is first filled by the source SDM kernel +virtio driver and sent over the gh_vq.