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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 044E0C2B9F4 for ; Mon, 14 Jun 2021 14:03:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BC67261360 for ; Mon, 14 Jun 2021 14:03:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234376AbhFNOF6 (ORCPT ); Mon, 14 Jun 2021 10:05:58 -0400 Received: from foss.arm.com ([217.140.110.172]:36916 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233293AbhFNOF4 (ORCPT ); Mon, 14 Jun 2021 10:05:56 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7549B1FB; Mon, 14 Jun 2021 07:03:53 -0700 (PDT) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 855953F70D; Mon, 14 Jun 2021 07:03:50 -0700 (PDT) Date: Mon, 14 Jun 2021 15:03:47 +0100 From: Cristian Marussi To: Christoph Hellwig Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, virtualization@lists.linux-foundation.org, virtio-dev@lists.oasis-open.org, sudeep.holla@arm.com, james.quinlan@broadcom.com, Jonathan.Cameron@huawei.com, f.fainelli@gmail.com, etienne.carriere@linaro.org, vincent.guittot@linaro.org, souvik.chakravarty@arm.com, igor.skalkin@opensynergy.com, peter.hilber@opensynergy.com, alex.bennee@linaro.org, jean-philippe@linaro.org, mikhail.golubev@opensynergy.com, anton.yakovlev@opensynergy.com, Vasyl.Vavrychuk@opensynergy.com, Andriy.Tryshnivskyy@opensynergy.com Subject: Re: [PATCH v4 00/16] Introduce SCMI VirtIO transport Message-ID: <20210614140347.GB35368@e120937-lin> References: <20210611165937.701-1-cristian.marussi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Christoph, On Mon, Jun 14, 2021 at 12:43:52PM +0100, Christoph Hellwig wrote: > On Fri, Jun 11, 2021 at 05:59:21PM +0100, Cristian Marussi wrote: > > Hi all, > > > > I'm posting this V4 series starting from the work done up to V3 by > > OpenSynergy. > > Who is 'OpenSynergy'? > > > The main aim of this rework is to simplify where possible the SCMI VirtIO > > support added in V3 by adding upfront and then using some new mechanisms in > > the SCMI Core Transport layer. > > And what is 'SCMI', and why would anyone want a new virtio transport? I'll start answering this last question first : SCMI stands for System Control and Management Interface whose latest specification can be found at: https://developer.arm.com/documentation/den0056/latest The spec aims to provide a common way to handle power & performance related needs by standardizing a set of protocols (clocks, power domains, sensors, voltages, resets, etc..) to enable an SCMI agent (Kernel) to talk to an external System Control Processor entity which acts as an SCMI Platform and satisfies (or denies) such requests in a centralized manner for the Kernel and any other SCMI agent present on system. Such SCMI stack can be indeed deployed in a variety of way depending on where the SCP running the SCMI Platofrm if physically situated: an external microntroller ? part of the EL-3 Platform firmware ? some functionality embedded in an Hypervisor ? a guest acting as an SCP ? Support for SCMI is already in mainline as of today under: drivers/firmware/arm_scmi But the currently existing transport mechanisms through which the SCMI agent and the platform talks are based on mailboxes or SMCs. In case the SCMI Stack is deployed in a virtualized environment we need some sort of SCMI transport that runs on VirtIO to establish comms between the VMs. OpenSynergy is an ARM partner who has deployed a virtualized SCMI stack in their own product and developed this series up to V3, taking care also the proposed related VirtIO spec changes: https://lists.oasis-open.org/archives/virtio-comment/202102/msg00018.html Such proposed VirtIO changes expose a new VirtiIO SCMI Device that represents the SCMI platform running the SCMI Server fw which answers the SCMI Kernel Agent requests. Similar approaches with virtualized SCMI stacks are being developed by Linaro and other partners as far as I know. I picked up this series from V4 since it was apparent that some changes were needed in the core SCMI stack to better integrate this new VirtIO transport that OpenSynergy developed up to V3. Hope to have been clear and concise (not really :D) enough. Thanks, Cristian 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=-5.5 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,USER_AGENT_SANE_1 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 27300C2B9F4 for ; Mon, 14 Jun 2021 14:05:23 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 E4A16610A2 for ; Mon, 14 Jun 2021 14:05:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E4A16610A2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bP5I91ZqNAEI5YxUV8dju2LeHfbSnHqvzS60PZqq85A=; b=waMDkCILJZLi4B pGfWjndEwtbkqlLxOM47m+4lFrdv/uGusPeZWtrPrySBczcDg+0V6d45tUDIjrLKekfwB0ZVI7ISI VcRrZ0XYEgZ1WcZpxo6A+Sa/o6zMSuxqgCDIT+eWxmX/lyynWx0PAtr4u7wmF+EmpRRIpeZhvbjBf odSPZSNgKMgw7Q/afOBSls5goVVF5UvGXqGgEM2zIFgpLg3F7tjIkEsPKT2qOnTBv8VlNOwAVzCs8 C03ESPMGDi5JbmGLIjIY3t8vl/4jnq+I1BFE/+Gsa6V8FRDm3OwNb0c8E7xnQYr80Onl5tBZJ3kq3 m91LoypH1iLSnjQ4WJTA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lsnC8-00EQhu-Dz; Mon, 14 Jun 2021 14:04:04 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lsnC3-00EQgJ-NK for linux-arm-kernel@lists.infradead.org; Mon, 14 Jun 2021 14:04:01 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7549B1FB; Mon, 14 Jun 2021 07:03:53 -0700 (PDT) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 855953F70D; Mon, 14 Jun 2021 07:03:50 -0700 (PDT) Date: Mon, 14 Jun 2021 15:03:47 +0100 From: Cristian Marussi To: Christoph Hellwig Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, virtualization@lists.linux-foundation.org, virtio-dev@lists.oasis-open.org, sudeep.holla@arm.com, james.quinlan@broadcom.com, Jonathan.Cameron@huawei.com, f.fainelli@gmail.com, etienne.carriere@linaro.org, vincent.guittot@linaro.org, souvik.chakravarty@arm.com, igor.skalkin@opensynergy.com, peter.hilber@opensynergy.com, alex.bennee@linaro.org, jean-philippe@linaro.org, mikhail.golubev@opensynergy.com, anton.yakovlev@opensynergy.com, Vasyl.Vavrychuk@opensynergy.com, Andriy.Tryshnivskyy@opensynergy.com Subject: Re: [PATCH v4 00/16] Introduce SCMI VirtIO transport Message-ID: <20210614140347.GB35368@e120937-lin> References: <20210611165937.701-1-cristian.marussi@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210614_070359_883827_25E9F3EA X-CRM114-Status: GOOD ( 20.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Hi Christoph, On Mon, Jun 14, 2021 at 12:43:52PM +0100, Christoph Hellwig wrote: > On Fri, Jun 11, 2021 at 05:59:21PM +0100, Cristian Marussi wrote: > > Hi all, > > > > I'm posting this V4 series starting from the work done up to V3 by > > OpenSynergy. > > Who is 'OpenSynergy'? > > > The main aim of this rework is to simplify where possible the SCMI VirtIO > > support added in V3 by adding upfront and then using some new mechanisms in > > the SCMI Core Transport layer. > > And what is 'SCMI', and why would anyone want a new virtio transport? I'll start answering this last question first : SCMI stands for System Control and Management Interface whose latest specification can be found at: https://developer.arm.com/documentation/den0056/latest The spec aims to provide a common way to handle power & performance related needs by standardizing a set of protocols (clocks, power domains, sensors, voltages, resets, etc..) to enable an SCMI agent (Kernel) to talk to an external System Control Processor entity which acts as an SCMI Platform and satisfies (or denies) such requests in a centralized manner for the Kernel and any other SCMI agent present on system. Such SCMI stack can be indeed deployed in a variety of way depending on where the SCP running the SCMI Platofrm if physically situated: an external microntroller ? part of the EL-3 Platform firmware ? some functionality embedded in an Hypervisor ? a guest acting as an SCP ? Support for SCMI is already in mainline as of today under: drivers/firmware/arm_scmi But the currently existing transport mechanisms through which the SCMI agent and the platform talks are based on mailboxes or SMCs. In case the SCMI Stack is deployed in a virtualized environment we need some sort of SCMI transport that runs on VirtIO to establish comms between the VMs. OpenSynergy is an ARM partner who has deployed a virtualized SCMI stack in their own product and developed this series up to V3, taking care also the proposed related VirtIO spec changes: https://lists.oasis-open.org/archives/virtio-comment/202102/msg00018.html Such proposed VirtIO changes expose a new VirtiIO SCMI Device that represents the SCMI platform running the SCMI Server fw which answers the SCMI Kernel Agent requests. Similar approaches with virtualized SCMI stacks are being developed by Linaro and other partners as far as I know. I picked up this series from V4 since it was apparent that some changes were needed in the core SCMI stack to better integrate this new VirtIO transport that OpenSynergy developed up to V3. Hope to have been clear and concise (not really :D) enough. Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel