Re: [PATCH v4 00/16] Introduce SCMI VirtIO transport

From: Cristian Marussi <cristian.marussi@arm.com>
To: Christoph Hellwig <hch@infradead.org>
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
Date: Mon, 14 Jun 2021 15:03:47 +0100	[thread overview]
Message-ID: <20210614140347.GB35368@e120937-lin> (raw)
In-Reply-To: <YMdA+GkgJ+GONuJr@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