From patchwork Fri Jun 17 16:03:14 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Pinto X-Patchwork-Id: 9184705 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 AFE31608A2 for ; Fri, 17 Jun 2016 17:30:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9142127EE2 for ; Fri, 17 Jun 2016 17:30:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 83A1328385; Fri, 17 Jun 2016 17:30:31 +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 E270427EE2 for ; Fri, 17 Jun 2016 17:30:29 +0000 (UTC) Received: from localhost ([::1]:59296 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDxbA-0006cI-WF for patchwork-qemu-devel@patchwork.kernel.org; Fri, 17 Jun 2016 13:30:29 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56553) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDwFR-00075J-Dp for qemu-devel@nongnu.org; Fri, 17 Jun 2016 12:03:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bDwFL-0003eZ-OC for qemu-devel@nongnu.org; Fri, 17 Jun 2016 12:03:56 -0400 Received: from mail-wm0-x242.google.com ([2a00:1450:400c:c09::242]:32813) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDwFL-0003eL-Do for qemu-devel@nongnu.org; Fri, 17 Jun 2016 12:03:51 -0400 Received: by mail-wm0-x242.google.com with SMTP id r201so803735wme.0 for ; Fri, 17 Jun 2016 09:03:51 -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=80eQ+dmADHObbG49fx3dVGmfJ9rvTTn9PbaYvMgE6+A=; b=nWn1GQYn/Rr8ukQOd4o3dLoL7UVqwplGKvv5b8NPJ+P2Jt62//FtG1bQodc7x5o4ZD 1HKlLazWpKSYLPEMz++2b8CVYb5Ag6cCZ/wFVzxlleX2D0aY1Uc1XLSsvTrref+9fnSA DHyEFEEZicqCv/Hj8lKZjQPKn4hKp5kyEx7Fuu2aJCiQ2/uA+fWgZAIptTHzEn+iyLIM JfFvSfJsoBjAD3QWHzTbq7jquWekTgVALuAqVLC5XF4eHA0zaRW3jfUPIJssoxeWB9rM 5jgib6gHjqCuKlAIdV5dwALBYJI1CIthlyzuows2+IojjB6c6Cw8qvO/rj9+Xwvzo3XI R02g== 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=80eQ+dmADHObbG49fx3dVGmfJ9rvTTn9PbaYvMgE6+A=; b=Pm0F6xHjEV7/ATuZG7TodS9HVUHLHLmvdda7RFcnG1EusNRRLvQjzIMPqHyRZ1AtQ9 QVI3BQuQI5rumY2sD23d1xPBr5EVFaDt31oGg6t/MnW/IkIBwj8jZiruvo5EV+nGPfhJ Z5QbOJz1ndZvjush3i2p9UEMFI+8dZD8yPljILU+ritsi4Ws/bg68W+esFFJ/+fSXS5U ekL6vdOfX6L1G+F7eDc0RHD/58tsSTR9PRzFzI/vsGyRTC9mvdjCqvhjsM7JaIEZV53A X0XLcBSKRUxWDqM3WDpjoLaA+If776OS/FMPzGNJUXlkf/W/H+TO01542OStEr+0iJMf 1Jcg== X-Gm-Message-State: ALyK8tKp/2S6E3Il6zN4H8b9q5vCqoE+vq8wqcPhM38p4qzofy4OoXm12PE7KsCXjcwk6Q== X-Received: by 10.194.178.199 with SMTP id da7mr3055899wjc.123.1466179430620; Fri, 17 Jun 2016 09:03:50 -0700 (PDT) Received: from bumma.localdomain ([151.67.13.17]) by smtp.googlemail.com with ESMTPSA id el4sm16742779wjd.23.2016.06.17.09.03.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 17 Jun 2016 09:03:49 -0700 (PDT) From: Christian Pinto To: virtio-dev@lists.oasis-open.org Date: Fri, 17 Jun 2016 18:03:14 +0200 Message-Id: <1466179394-4744-3-git-send-email-c.pinto@virtualopensystems.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1466179394-4744-1-git-send-email-c.pinto@virtualopensystems.com> References: <1466179394-4744-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::242 Subject: [Qemu-devel] [virtio-dev][RFC 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 , 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 --- virtio-sdm.tex | 126 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 virtio-sdm.tex diff --git a/virtio-sdm.tex b/virtio-sdm.tex new file mode 100644 index 0000000..abbdb80 --- /dev/null +++ b/virtio-sdm.tex @@ -0,0 +1,126 @@ +\section{Signal Distribution Module}\label{sec:Device Types / SDM Device} + +The virtio Signal Distribution Module is meant to enable Inter Processor +interrupts in QEMU/KVM environment. The SDM enables different processors in the +same or different QEMU instances to send mutual signals. 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. + +\subsection{Device ID}\label{sec:Device Types / SDM Device / Device ID} + +19 + +\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 host-guest communication (i.e., notification of a signal), +while queue 1 for guest-host 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 +Linux 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. +The value of \texttt{max_slaves} is initially set from the command line of QEMU, +but can be changed during operations through the configuration space. +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 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 that is specificied as a parameter when configuring the device. At the +current state there are two types of communication channels: local and +socket(TCP or UNIX). +The local channel is meant for SDM devices attached to the same QEMU instance, +while the network channel makes it possible to exchange signals between +SDMs in different instances of QEMU. +The type of communication channel is chosen at QEMU boot time and cannot be +changed during operations. It has to be noted that the behavior of the device is +independent from the communication channel used. + +\subsection{Device Operation}\label{sec:Device Types / SDM Device / Device +peration} + +The SDM device handles signal coming from the two following sources: + +\begin{enumerate} +\item The local processor to which the devics 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 SDM device instance (being it the same QEMU instance or a +separate one). +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 themsleves 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 use case for the payload field is a hardware mailbox, where data is +pushed into the mailbox and an interrupt is triggered towards all the devices +registered with the mailbox. + +The \texttt{SDMSignalData} structure is first filled by the source SDM kernel +virtio driver and sent over the gh_vq.