On Mon, Nov 15, 2021 at 10:13:59AM +0000, Cristian Marussi wrote:
> Hi,
>
> this short series aims mainly to introduce support (in [01/02]) for the
> emulation of a VirtIO SCMI Device as per the VirtIO specification in [1].
>
> Afterwards, as a related but independent patch, general support for
> FDT Overlays is also added in [02/02], since this latter is needed to
> craft more complex DT configurations needed from time to time with SCMI
> for testing/development purposes.
>
> Generally, ARM SCMI protocol [2] defines how an SCMI platform server can
> talk with a number of SCMI Agents (like a Linux Kernel implementing the
> SCMI stack) to manage and control various aspects of System power and
> performance.
>
> An SCMI Platform firmware could already reside in a number of places and,
> with the recent addition of a VirtIO transport layer in the Linux SCMI
> stack, the SCMI backend can also be deployed in a virtualized environment,
> represented by an emulated VirtIO SCMI Device.
>
> Since it is clearly not advisable/sensible to implement the whole SCMI
> Server backend logic inside kvmtool (i.e. the SCMI fw), the proposed
> emulated SCMI device will indeed act as 'proxy' device, routing the
> VirtIO SCMI traffic received from the guest OSPM SCMI Agent virtqueues
> back and forth to some external userspace application (acting as an SCMI
> Server) via Unix sockets.
>
> The aim of this addition to kvmtool is to provide an easy way to debug
> and test the SCMI Kernel stack in the guest during development, so that it
> should be possible to exercise the Kernel SCMI stack without the need to
> have a fully compliant SCMI hw and fw in place: the idea is to be able to
> use as the FW userspace emulation backend (reachable via Unix sockets), a
> simpler stripped down SCMI server supporting only mocked HW and easily
> extendable but also simply configurable to misbehave at will at the SCMI
> protocol level.
>
> For testing purposes using such a simplified server should be easier than
> using a fully compliant one when it comes to:
>
> - implement a new protocol support backend to test the Kernel brand new
> implementation before some official full SCMI fw support is made
> available (if ever in case of custom vendor protocols)
>
> - mock a variety of fake HW for testing purposes without worrying about
> real HW (all is mocked really...)
>
> - force some sort of misbehaviour at the SCMI protocol layer to test
> the robustness of the Kernel implementation (i.e. late/duplicated/
> unexpected/out-of-order/malformed SCMI Replies): a fully fledged
> official SCMI Server implementation is NOT meant/designed to misbehave
> so it's harder to make it do it.
>
> The reason I'm posting this as an RFC is mainly because of the usage of
> the custom Unix sockets interface to relay SCMI messages to userspace: this
> is easier and is sufficient for our testing/development scenario above, but
> it is clearly a non standard approach: a more standard way would be to use
> the vhost-user protocol to negotiate the direct sharing of the SCMI vqueues
> between the guest and the userspace FW emulation.
>
> Such alternative solution would have the main advantage to be able to
> interface also with the standard full fledged SCP SCMI Firmware Server
> (for validation purposes ?) which is recently adding support [3] to be run
> as a vhost-user server: the drawback instead would be the added complexity
> to kvmtool and especially to the simplified userspace SCMI emulation server
> I was blabbing about above (and the fact that the whole vhost-user support
> would have to be added to kvmtool at first and I'm not sure if that is
> something wanted given its nature of an hack tool...but I'd be happy to
> add it if deemed sensible instead...)
>
> Based on kvmtool:
>
> commit 39181fc6429f ("vfio/pci: Align MSIX Table and PBA size to guest
> maximum page size")
>
> Any feedback welcome !
>
> Thanks,
> Cristian
>
Hi,
after a quick offline discussion with Alexandru (thanks !) it's agreed
that this series should not be merged upstream for now given the current
lack of a generally available and open source SCMI userspace server
backend implementation that can talk with the SCMI proxy device
introduced by this series.
Thanks,
Cristian
