kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH kvmtool 0/2] Introduce VirtIO SCMI Device support
@ 2021-11-15 10:13 Cristian Marussi
  2021-11-15 10:14 ` [RFC PATCH kvmtool 1/2] virtio: Add support for VirtIO SCMI Device Cristian Marussi
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Cristian Marussi @ 2021-11-15 10:13 UTC (permalink / raw)
  To: kvm, will, julien.thierry.kdev
  Cc: andre.przywara, sudeep.holla, alexandru.elisei, james.morse,
	Cristian Marussi

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

[1]: https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-scmi.tex
[2]: https://developer.arm.com/documentation/den0056/latest
[3]: https://github.com/ARM-software/SCP-firmware/pull/524
----
Cristian Marussi (2):
  virtio: Add support for VirtIO SCMI Device
  arm/fdt: Add FDT overlay support

 Makefile                                 |   1 +
 arm/fdt.c                                |  38 ++
 arm/include/arm-common/kvm-config-arch.h |  23 +-
 arm/include/arm-common/scmi.h            |   6 +
 include/kvm/virtio-pci-dev.h             |   2 +
 include/kvm/virtio-scmi.h                |   9 +
 include/linux/virtio_ids.h               |   1 +
 include/linux/virtio_scmi.h              |  43 ++
 virtio/scmi.c                            | 656 +++++++++++++++++++++++
 9 files changed, 778 insertions(+), 1 deletion(-)
 create mode 100644 arm/include/arm-common/scmi.h
 create mode 100644 include/kvm/virtio-scmi.h
 create mode 100644 include/linux/virtio_scmi.h
 create mode 100644 virtio/scmi.c

-- 
2.17.1


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-02-16 12:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-15 10:13 [RFC PATCH kvmtool 0/2] Introduce VirtIO SCMI Device support Cristian Marussi
2021-11-15 10:14 ` [RFC PATCH kvmtool 1/2] virtio: Add support for VirtIO SCMI Device Cristian Marussi
2021-11-15 10:14 ` [RFC PATCH kvmtool 2/2] arm/fdt: Add FDT overlay support Cristian Marussi
2022-02-16 11:59 ` [RFC PATCH kvmtool 0/2] Introduce VirtIO SCMI Device support Cristian Marussi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).