Messages in this thread | | | Date | Mon, 14 Jun 2021 15:03:47 +0100 | From | Cristian Marussi <> | Subject | Re: [PATCH v4 00/16] Introduce SCMI VirtIO transport |
| |
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
| |