Re: [PATCH v5 00/23] Introduce SCMI Telemetry support

Re: [PATCH v5 00/23] Introduce SCMI Telemetry support

[Cristian Marussi]

On Thu, Jul 09, 2026 at 03:46:23AM +0100, Fayssal Benmlih wrote:
>    Overall, v5 is a good direction: dropping the filesystem ABI for a
>    chardev/ioctl ABI is simpler, easier to version, and more appropriate
>    for high-rate telemetry. The split between SCMI protocol support, UAPI,

Hi Fayçal,

in fact this same IOCTLs based interface (even if more rough) was also present in
the defunct FS approach, attached to the special 'control' files...nothing new
really...but a lot of rework and testing needed for sure...

>    driver, docs, and test tool is also much cleaner. The main concern is
>    that there are several correctness and usability issues that should be
>    fixed before merge.

... of course, since this is the first ever posting with the IOCTLs being
the main and only ABI, it was never meant to be straight away ready for merge,
as I mentioned in the cover-letter there are a few TBD still pending and a
lot of cleanups as reported by the LLM reviews too... Sashiko is one great
example of existing LLM reviewing Kernel patches...

...some of these points are pretty much valid (also Sashiko has a few more
complaints) and I will take care of those....but some other are compeletely
OR slightly off, I will go through those in the following...

> 
>    Must-Fix Issues
>      * scmi_tlm_to_uapi_base_info() uses out->flags |= ... on an
>        uninitialized local struct scmi_tlm_base_info base; this can leak
>        garbage flags. Use out->flags = ... or zero-initialize base.
>      * scmi_tlm_update_interval.exp is documented and used as signed, but
>        the UAPI declares it as __u32. It should be __s32, otherwise
>        examples like exp = -3 are ABI-broken.
>      * Group bounds checks use grp_id > num_groups; they should use grp_id
>        >= num_groups to avoid out-of-bounds access.
>      * Avoid casting UAPI integer fields to bool *, especially __u32
>        enable/t_enable in scmi_tlm_de_config. Use local bool enable =
>        !!tcfg.enable; variables and copy normalized values back explicitly
>        if needed.
>      * Array sizes from userspace need overflow and allocation hardening:
>        use array_size(), kvmalloc_array(), and clear max limits for
>        num_des, num_samples, num_grps, etc.

I really dont understand this, since the user allocates the buffers, that he
then provides via a __u64 ptr, and such allocation happens based on the maximum
number of items the platform has declared to exist (like num_des) so if the user
itself had lied or mistakenly provided a smaller buffer then declared, that is a
user problem that will trapped and result in a SIGSEGV (or a userspace malloc
corruption)...here a specific reference to the actual code causing the supposed
issue would have helped...

>      * SCMI_TLM_GET_SHMTI_LIST loops over the user-provided count after
>        only checking it is not too small; if it is too large it can read
>        beyond in->shmtis[]. Loop over the actual firmware count.

Yes I definitely loop mistakenly on the wrong variable, BUT the missing
check on the too-large condition is an explicit design decision so that
userspace can optionally use the same common big buffer as a scratch
buffer to collect multiple kind of enumeration data...but of course the
loop must happen on the what is available in system NOT on what the user
has passed in...

>      * The mmap path needs tighter validation: reject oversized mappings,
>        handle mmap offsets deliberately, set appropriate VMA flags, and
>        document the lifetime/security model for exposed SHMTI memory.

Beside a bit of hardening, I think here the only missing part is documenting
that you get direct RO access to an SCMI Telemetry area and that you are on
your own in how to parse that...format and lifetime is as specified in SCMIv4.0

Cannot do any deliberate offset handling really...any neeed offset is
dynamically discovered and communicated at runtime via SCMI_TLM_GET_SHMTI_LIST
(offset is rarely different than 0, ONLY if FW has NOT exposed such areas as
page aligned)

..probably worth security wise to check that FW shared areas are
properly page aligned (to the max 64k) and that nothing crititical lays
around when not aligned...so that I dont accidentally expose some other
bits of FW...but I cannot really check so much here from kernel Point of
view...mmm...maybe that the surrounding bytes are zeroed by FW ?

> 
>    Design Feedback
>      * No ABI version/capability ioctl. GET_INFO gives protocol/platform
>        info, but userspace also needs driver ABI version and supported
>        ioctl feature bits.
>      * Enumeration is awkward. List ioctls should support a clear two-call
>        pattern: call with count 0 to get required count, allocate, call
>        again. Returning EINVAL for “buffer too small” is not very
>        ergonomic.

Well the only reason I have NOT implemented this idiom is that all of
this enumeration data is basically static RO (at least within the same
boot), so you can know very well in advance how many elements you have
by calling upfront just one single time SCMI_TLM_GET_INFO, instead of
having to issue twice each IOCTL to know how big the input buffer should
be...but I can implement also this idiomatic form in v6 of course as an
alternative mechanism if we want to support the standard/classic idiom...
...it will be certainly less performant by duplicating all IOCTLs calls x 2...

I will probably rework SCMI_TLM_GET_INFO, to be the new SCMI_TLM_GET_ABI_INFO
including version/capability/resource info IOCTLs...so that you can get the ABI
version, lookup feature bits and get the numebr of resources (like it is
now..to size the requests...)

>      * No generation counter yet. Userspace needs to detect
>        config/resource changes between discovery and read. This should
>        probably land with the first ABI.

Yes that is NOT in this version, but it is definitely planned for this
series: there will be a way to read and more importantly some poll
support based on eventfd.

>      * Global config is dangerous. SET_CFG, SET_DE_CFG, and
>        SET_ALL_CFG mutate shared firmware state. Multiple users can race
>        or disrupt each other. Consider documenting ownership semantics,
>        adding locking/session model, or exposing read-only access
>        separately.

Yes, this is the same as in the FS approach, multiple reader and writers
can coexist BUT the Kernel does NOT mediate concurrent configuration
attempts, last writer wins: kernel only guarantes serialization when
multiple configs are written...but anyway last wins.

>      * SET_ALL_CFG is not atomic. If configuring all DEs fails midway,
>        userspace gets partial state. Either make that explicit, add
>        rollback/best-effort reporting, or prefer batched config with
>        per-item status.

Mmm...if SET_ALL_CFG fails midway, an error is reported and the
subsequent GET_ALL_CFG will return the current state of 'ALL':
i.e. True if all enabled, False if any is disabled...

You can anyway lookup each single DE state subsequently.

I could implement an all or nothing with rollback but I am not sure the
complication in code is worth: on the other side I was thinking too about
the optional batched config as mentioned as a way to speed up multiple
configs mostly...

>      * No event/poll model. For telemetry, userspace may want
>        poll()/blocking reads/notification-driven collection rather than
>        repeated synchronous ioctls.

Yes that is the future plan and most of the internal support is already in
place, I have not planned any dedicated IOCTL till now (similarly there was
no dedicated special file in the old FS approach) since, for such streaming
poll model to be feasible, SCMI Telemetry notifications are needed, but they
are optional by the spec and currently NOT planned FW side AFAIK... so I
lowered this in priority and delayed to a future extensions given the
increasingly tight timeline that we have. (even though I can devel and
plan against my emulation setup..)

I would like anyway to add a generic event IOCTL that allows the user to
register a custom eventfd for a specific event to be monitored....first
event being the generation counter change AND second the update
notification for event/poll telemetry ocnsumption....

>      * Timestamp usability is underspecified. Userspace needs clear
>        timestamp domain, rate conversion, wrap behavior, and correlation
>        to Linux clocks.

All of the timestamps are originated by the platform and specified by
the SCMI spec: Kernel does NOT mediate/correct/trim anything here.

It will have to be documented better of course, but all you get is a 64
bit tinestamp and the clock rate in KhZ that has been used to generate
this specific timestamp for this DE..

>      * Raw SHMTI mmap is powerful but has risks. It needs very clear
>        lifetime, permissions, cacheability, offset/length, stale-data, and
>        security documentation.

>      * Batch APIs lack per-sample status. In BATCH_READ, one bad DE
>        currently appears to fail the whole request. For tools, per-entry
>        status is much better.

Can add status.

>      * Text read() plus binary ioctls feels split-brain. Either document
>        read() as debug/convenience only, or remove it from the stable
>        interface and keep the ABI purely binary; no need for two different
>        user interfaces with different semantics.

This was to try to supply some form of tool-independent human readable access
...indeed I was also tempted to re-introduce a limited form of proper SysFs for
global configs like update interval or global tlm_enable...(but not sure
about this really...)

>      * Rename the generic #define SCMI 0xF1 to something scoped like
>        SCMI_TLM_IOCTL_MAGIC; exporting a broad SCMImacro in UAPI is
>        collision-prone.
>      * Add .compat_ioctl = compat_ptr_ioctl or equivalent, and document
>        that all structs are 32/64-bit compatible. The __u64user pointers
>        help, but compat behavior should be explicit.
>      * Clarify concurrency semantics: what happens when two processes
>        enable/disable DEs, change intervals, or read while config changes?
>        A generation counter/reset ioctl, already listed as TODO, should
>        probably be part of the first ABI version.

No kernel mediation on this, ONLY a generation counter to spot unexpected
changes.

>      * Define permissions. Configuration ioctls mutate global firmware
>        telemetry state, so access control/default device mode/udev
>        expectations should be documented.
> 

As of now, no policying, whoever is privileged enough to write to the
device can configure the system, last writer wins.
Being now all of this based on a bunch of single devices (one per instance),
it could be more feasible to enable some sort of optional exclusive open mode
for the first privileged user to get hold of the device...I'll reason about it.

>    Suggested additions before ABI freeze
>      * SCMI_TLM_GET_ABI_INFO
>      * SCMI_TLM_GET_GENERATION
>      * SCMI_TLM_RESET
>      * batched GET/SET_DE_CFG with per-entry status
>      * pollable notification/event support, if telemetry notifications are
>        meaningful to userspace
>      * optional read-only open mode or permission model for non-mutating
>        tools
> 
>    Usability / Docs
>      * The docs need more precise examples for two-call enumeration, error
>        handling, batch reads, and mmap cleanup/close semantics.

Yes that was minimal on purpose, given this was the first shot and a lot
can still change...

>      * Fix typos before reposting: “Systemn”, “dwscriptors”, “istance”,
>        “udpated”, “andc”, “A IOCTL”.
>      * The sample tool should either be promoted into a real
>        selftest-style utility or clearly kept out of the upstreamable set
>        until it has robust argument parsing and error reporting.
> 

Well...the tool as of now if a draft thing for testing...it is indeed
marked as RFC (and declared in a crappy state)...so it is clear NOT for
upstream as it is: as I mentioned in the commit itself it is meant to be
improved and used for testing in the future...not for upstream in this
state of course...

...BUT even in this state can be used to simply exercise most of the
IOCTL quickly...so that was the reason I included it as  RFC.

Thanks,
Cristian

Re: [PATCH v5 00/23] Introduce SCMI Telemetry support

[Fayssal Benmlih]

Overall, v5 is a good direction: dropping the filesystem ABI for a chardev/ioctl ABI is simpler, easier to version, and more appropriate for high-rate telemetry. The split between SCMI protocol support, UAPI, driver, docs, and test tool is also much cleaner. The main concern is that there are several correctness and usability issues that should be fixed before merge.

Must-Fix Issues

-scmi_tlm_to_uapi_base_info() uses out->flags |= ... on an uninitialized local struct scmi_tlm_base_info base; this can leak garbage flags. Use out->flags = ... or zero-initialize base.
-scmi_tlm_update_interval.exp is documented and used as signed, but the UAPI declares it as __u32. It should be __s32, otherwise examples like exp = -3 are ABI-broken.
-Group bounds checks use grp_id > num_groups; they should use grp_id >= num_groups to avoid out-of-bounds access.
-Avoid casting UAPI integer fields to bool *, especially __u32 enable/t_enable in scmi_tlm_de_config. Use local bool enable = !!tcfg.enable; variables and copy normalized values back explicitly if needed.
-Array sizes from userspace need overflow and allocation hardening: use array_size(), kvmalloc_array(), and clear max limits for num_des, num_samples, num_grps, etc.
-SCMI_TLM_GET_SHMTI_LIST loops over the user-provided count after only checking it is not too small; if it is too large it can read beyond in->shmtis[]. Loop over the actual firmware count.
-The mmap path needs tighter validation: reject oversized mappings, handle mmap offsets deliberately, set appropriate VMA flags, and document the lifetime/security model for exposed SHMTI memory.

Design Feedback

-No ABI version/capability ioctl. GET_INFO gives protocol/platform info, but userspace also needs driver ABI version and supported ioctl feature bits.
-Enumeration is awkward. List ioctls should support a clear two-call pattern: call with count 0 to get required count, allocate, call again. Returning EINVAL for “buffer too small” is not very ergonomic.
-No generation counter yet. Userspace needs to detect config/resource changes between discovery and read. This should probably land with the first ABI.
-Global config is dangerous. SET_CFG, SET_DE_CFG, and SET_ALL_CFG mutate shared firmware state. Multiple users can race or disrupt each other. Consider documenting ownership semantics, adding locking/session model, or exposing read-only access separately.
-SET_ALL_CFG is not atomic. If configuring all DEs fails midway, userspace gets partial state. Either make that explicit, add rollback/best-effort reporting, or prefer batched config with per-item status.
-No event/poll model. For telemetry, userspace may want poll()/blocking reads/notification-driven collection rather than repeated synchronous ioctls.
-Timestamp usability is underspecified. Userspace needs clear timestamp domain, rate conversion, wrap behavior, and correlation to Linux clocks.
-Raw SHMTI mmap is powerful but has risks. It needs very clear lifetime, permissions, cacheability, offset/length, stale-data, and security documentation.
-Batch APIs lack per-sample status. In BATCH_READ, one bad DE currently appears to fail the whole request. For tools, per-entry status is much better.
-Text read() plus binary ioctls feels split-brain. Either document read() as debug/convenience only, or remove it from the stable interface and keep the ABI purely binary; no need for two different user interfaces with different semantics.
-Rename the generic #define SCMI 0xF1 to something scoped like SCMI_TLM_IOCTL_MAGIC; exporting a broad SCMImacro in UAPI is collision-prone.
-Add .compat_ioctl = compat_ptr_ioctl or equivalent, and document that all structs are 32/64-bit compatible. The __u64user pointers help, but compat behavior should be explicit.
-Clarify concurrency semantics: what happens when two processes enable/disable DEs, change intervals, or read while config changes? A generation counter/reset ioctl, already listed as TODO, should probably be part of the first ABI version.
-Define permissions. Configuration ioctls mutate global firmware telemetry state, so access control/default device mode/udev expectations should be documented.

Suggested additions before ABI freeze

-SCMI_TLM_GET_ABI_INFO
-SCMI_TLM_GET_GENERATION
-SCMI_TLM_RESET
-batched GET/SET_DE_CFG with per-entry status
-pollable notification/event support, if telemetry notifications are meaningful to userspace
-optional read-only open mode or permission model for non-mutating tools

Usability / Docs

-The docs need more precise examples for two-call enumeration, error handling, batch reads, and mmap cleanup/close semantics.
-Fix typos before reposting: “Systemn”, “dwscriptors”, “istance”, “udpated”, “andc”, “A IOCTL”.
-The sample tool should either be promoted into a real selftest-style utility or clearly kept out of the upstreamable set until it has robust argument parsing and error reporting.

Bottom Line

The architecture is promising, but the UAPI needs one more hardening pass before it becomes ABI: The ioctl set covers the basic workflow, but some parts are still hard for user space tools to consume robustly, especially around discovery, concurrency, partial failure, and long-running collection. Those should be fixed before treating the UAPI as stable. I would also focus v6 on fixing the concrete correctness bugs, tightening mmap/security semantics, adding compat support, and making enumeration/configuration behavior predictable for production userspace.

-Fayçal

[PATCH v5 00/23] Introduce SCMI Telemetry support

[Cristian Marussi]

Hi all,

[TLDR Summary]
 - This series introduces a new driver to support ARM SCMI Telemetry
 - The previous (till v4) FS-based ABI driver is gone: no equivalent
   FUSE support is planned, either, due to the implicit performance hit
 - A new simple chardev driver exposing am IOCTLs ABI is proposed
 - V5 focus is on the new UAPI (i.e. definitely missing to address some
   previous V4 reviews...they will be taken care in v6)

The upcoming SCMI v4.0 specification [0] introduces a new SCMI protocol
dedicated to System Telemetry.

In a nutshell, the SCMI Telemetry protocol allows an agent to discover at
runtime the set of Telemetry Data Events (DEs) available on a specific
platform and provides the means to configure the set of DEs that a user is
interested into, while reading them back using the collection method that
is deeemed more suitable for the usecase at hand. (...amongst the various
possible collection methods allowed by SCMI specification)

Without delving into the gory details of the whole SCMI Telemetry protocol
let's just say that the SCMI platform/server firmware advertises a number
of Telemetry Data Events, each one identified by a 32bit unique ID, and an
SCMI agent/client, like Linux, can discover them and read back at will the
associated data value in a number of ways.
Data collection is mainly intended to happen on demand via shared memory
areas exposed by the platform firmware, discovered dynamically via SCMI
Telemetry and accessed by Linux on-demand, but some DE can also be reported
via SCMI Notifications asynchronous messages or via direct dedicated
FastChannels (another kind of SCMI memory based access): all of this
underlying mechanism is anyway hidden to the user since it is mediated by
the kernel driver which will return the proper data value when queried.

Anyway, the set of well-known architected DE IDs defined by the spec is
limited to a dozen IDs, which means that the vast majority of DE IDs are
customizable per-platform: as a consequence, though, the same ID, say
'0x1234', could represent completely different things on different systems.

Precise definitions and semantic of such custom Data Event IDs are out of
the scope of the SCMI Telemetry specification and of this implementation:
they are supposed to be provided using some kind of JSON-like description
file that will have to be consumed by a userspace tool which would be
finally in charge of making sense of the set of available DEs.

IOW, in turn, this means that even though the DEs enumerated via SCMI come
with some sort of topological and qualitative description provided by the
protocol (like unit of measurements, name, topology info etc), kernel-wise
we CANNOT be completely sure of "what is what" without being fed-back some
sort of information about the DEs by the afore mentioned userspace tool.

For these reasons, currently this series does NOT attempt to register any
of these DEs with any of the usual in-kernel subsystems (like HWMON, IIO,
PERF etc), simply because we cannot be sure which DE is suitable, or even
desirable, for a given subsystem. This also means there are NO in-kernel
users of these Telemetry data events as of now.

So, while we do not exclude, for the future, to feed/register some of the
discovered DEs to/with some of the above mentioned Kernel subsystems, as
of now we have ONLY modeled a custom userspace API to make SCMI Telemetry
available to userspace tools.

With V5 we drop the FS-based ABI approach, as it has been recently rejected
upstream, and we move to a pure chardev/IOCTL approach.

INTERFACES

For each discovered SCMI Instance a character device named tlm_<N> is
created under /dev/scmi/ subtree.

The IOCTL interface described at 'include/uapi/linux/scmi.h' is made
available to enumerate and configure Telemetry resources: Telemetry data
can be collected using a few different IOCTls, depending on the required
granularity.

Alternatively it is possible to obtain a list of the file descriptors
referencing directly the underlying SCMI Telemetry SHMTI memory areas and
implement in user space an SCMI Telemetry parser accessing directly the
SHMTI, while staying in compliance with the SCMI TDCF format.

NOTE THAT from v3 onwards the firmware interface level NOW supports ONLY
the latest SCMI v4.0 specification [0].

KNOWN ISSUES/IMPROVEMENTS/TODO
 - still to look at Sashiko complaints
 - a few V4-related review comments to address
 - review SCMI Telemetry in-protocol notification handling
 - maybe better to have a single unified TLM_CFG IOCTL with a variable
   payload composed of TLV items ?
 - what about RO static resource enumeration via mmaped areas as an
   alternative to a bunch of enumeration IOCTLs that we have now ?
 - maybe better to have one single mmap'able area where all the TDCFs
   are collected at proper offsets, instead of one distinct mmap for each
   TDCF ?
 - add generation counter IOCTL support
 - add Telemetry RESET IOCTL support
 - stlm tool utility is crappy and minimal ... as of now just for testing
   or development...serious rework needed to make it upstreamable

Based on V7.2-rc1, tested on an emulated setup.

This series is available also at [1].

If you still reading...any feedback welcome :P

Thanks,
Cristian

----
v4 --> v5
 - rebased on v7.2-rc1
 - dropped FileSystem based driver
 - introduced a new simple chardev SCMI driver using Telemetry
 - reworked/reviewed the v4 IOCTLs based UAPI
 - UAPI: better struct alignment and comments
 - UAI: Removed flexible array members
 - UAPI: make SCMI Telemetry protocol stack completely independent from
 	 uapi defs
 - UAPI: new ioctls support to enable RAW mmap direct access to SCMI SHMTI
 	 areas from userspace
 - added new ABI Documentation
 - added new SCMI core facility to lookup the current SCMI instance ID
v3 --> v4
 - rebased on v7.1-rc7
 - updatded doc to detail Concurrency model
 - bail out on FW_BUG errors
 - make all_des_enable/all_des_tstamp_enable entry readable
 - refactored access to TDE values
 - refactored common accessors for tlm_priv (FIX WARN on kfree)
 - make all files by default world readable and user writable (if needed)
 - added uid/god/umask mount options (and docs)
 - added generation counter to aid spotting config changes (and docs)
 - added DebugFS configurable support to debug/dump SHMTI areas (and docs)
 - hide FS entries when NOT supported (like des_simple_sample_read)
 - fixed output format of des/<NNN>/value to -> <TS> <VALUE>
 - renamed top-dir by_components to by-components
 - add a .remove method to SCMI System Telemetry Driver
 - use kzalloc_obj
V2 --> V3
 - rebased on v7.0-rc5
 - ported the firmware interface to SCMI v4.0 BETA
 - split the SCMI protocol layer in a lot of small patches
 - completd filesystem and ABI documentation
 - renamed components subtree to by_components
 - fixed uninitialized var in scmi_telemetry_de_subdir_symlink
 - renamd tstamp_exp to tstamp_rate
 - swap logic in scmi_telemetry_initial_state_lookup
 - use memcpy_from_le32 where required
 - changed a dfew dev_err into Telemetry traces
 - define and use new helper scmi_telemetry_de_unlink
 - simplify a few assignments with ternary ops
 - added a missing __mmust_check on the internal SCMI API
 - reworked and clarified de_data_read returned errno:
 	ENODATA vs EINVAL vs ENODEV/ENOENT
 - removed some risky/unneeded devres allocations
 - various checkpatch fixes
 - reworked and clarified usage of traces in Telemetry
 - added the missing DT binding for protocol 0x1B
 - split out unrelated change around notification from patch
   adding support for protocol internal notifier
 - more comments

V1 --> V2
 - rebased on v6.19-rc3
 - harden TDCF shared memory areas accesses by using proper accessors
 - reworked protocol resources lifecycle to allow lazy enumeration
 - using NEW FS mount API
 - reworked FS inode allocation to use a std kmem_cache
 - fixed a few IOCTLs support routine to support lazy enumeration
 - added (RFC) a new FS lazy mount option to support lazily population of
   some subtrees of the FS (des/ groups/ components/)
 - reworked implementation of components/ alternative FS view to use
   symlinks instead of hardlinks
 - added a basic simple (RFC) testing tool to exercise UAPI ioctls interface
 - hardened Telmetry protocol and driver to support partial out-of-spec FW
   lacking some cmds (best effort)
 - reworked probing races handling
 - reviewed behaviour on unmount/unload
 - added support for Boot_ON Telemetry by supporting SCMI Telemetry cmds:
   + DE_ENABLED_LIST
   + CONFIG_GET
 - added FS and ABI docs

RFC --> V1
---
 - moved from SysFS/chardev to a full fledged FS
 - added support for SCMI Telemetry BLK timestamps


Thanks,
Cristian

[0]: https://developer.arm.com/documentation/den0056/f/?lang=en
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/cris/linux.git/log/?h=scmi_telemetry_ng_V5

Cristian Marussi (23):
  firmware: arm_scmi: Add new SCMIv4.0 error codes definitions
  firmware: arm_scmi: Reduce the scope of protocols mutex
  firmware: arm_scmi: Allow registration of unknown-size events/reports
  firmware: arm_scmi: Allow protocols to register for notifications
  dt-bindings: firmware: arm,scmi: Add support for telemetry protocol
  include: trace: Add Telemetry trace events
  firmware: arm_scmi: Add basic Telemetry support
  firmware: arm_scmi: Add support to parse SHMTIs areas
  firmware: arm_scmi: Add Telemetry configuration operations
  firmware: arm_scmi: Add Telemetry DataEvent read capabilities
  firmware: arm_scmi: Add support for Telemetry reset
  firmware: arm_scmi: Add Telemetry notification support
  firmware: arm_scmi: Add support for boot-on Telemetry
  firmware: arm_scmi: Add Telemetry generation counter
  firmware: arm_scmi: Add common per-protocol debugfs support
  firmware: arm_scmi: Add Telemetry debugfs SHMTI dump support
  firmware: arm_scmi: Add Telemetry debugfs ABI documentation
  firmware: arm_scmi: Expose per-instance identifier
  uapi: Add ARM SCMI Telemetry definitions
  firmware: arm_scmi: Add System Telemetry driver
  docs: ioctl-number: Add SCMI Ioctls
  Documentation: Add SCMI System Telemetry documentation
  [RFC] tools/scmi: Add SCMI Telemetry testing tool

 Documentation/ABI/testing/debugfs-scmi        |   22 +
 .../bindings/firmware/arm,scmi.yaml           |    8 +
 Documentation/userspace-api/index.rst         |    1 +
 .../userspace-api/ioctl/ioctl-number.rst      |    1 +
 Documentation/userspace-api/stlm.rst          |  143 +
 MAINTAINERS                                   |    1 +
 drivers/firmware/arm_scmi/Kconfig             |   24 +
 drivers/firmware/arm_scmi/Makefile            |    3 +-
 drivers/firmware/arm_scmi/common.h            |   10 +
 drivers/firmware/arm_scmi/driver.c            |   93 +-
 drivers/firmware/arm_scmi/notify.c            |   30 +-
 drivers/firmware/arm_scmi/notify.h            |    8 +-
 drivers/firmware/arm_scmi/protocols.h         |   13 +
 .../firmware/arm_scmi/scmi_system_telemetry.c | 1233 ++++++
 drivers/firmware/arm_scmi/telemetry.c         | 3318 +++++++++++++++++
 include/linux/scmi_protocol.h                 |  254 +-
 include/trace/events/scmi.h                   |   48 +-
 include/uapi/linux/scmi.h                     |  359 ++
 tools/testing/scmi/Makefile                   |   25 +
 tools/testing/scmi/stlm.c                     |  648 ++++
 20 files changed, 6202 insertions(+), 40 deletions(-)
 create mode 100644 Documentation/userspace-api/stlm.rst
 create mode 100644 drivers/firmware/arm_scmi/scmi_system_telemetry.c
 create mode 100644 drivers/firmware/arm_scmi/telemetry.c
 create mode 100644 include/uapi/linux/scmi.h
 create mode 100644 tools/testing/scmi/Makefile
 create mode 100644 tools/testing/scmi/stlm.c

-- 
2.54.0

Re: [PATCH v5 00/23] Introduce SCMI Telemetry support

[Subrahmanya Lingappa]

Hi Cristian,

Thanks for posting this. I think the direction of not forcing these
Telemetry Data Events into hwmon/IIO/perf prematurely is the right one.
The cover letter explains the core problem well: most DE IDs are
platform-defined, and without external metadata the kernel cannot reliably
know whether a DE is a thermal sensor, a performance counter, a power value,
or something entirely platform-specific.

That said, I think the current layering is still too SCMI-shaped for the
ABI it is trying to introduce.

The thing being exposed here is not only "SCMI Telemetry"; it is a more
general kernel concept of telemetry:

  - enumerate provider-specific data/event descriptors
  - expose capabilities, units, data format and topology/grouping metadata
  - configure collection rate and collection mode where supported
  - collect samples with timestamp/freshness/validity information
  - track generation/state changes
  - optionally expose provider-private raw backing storage for debugging

SCMI is one provider of that model. It happens to transport the data through
SCMI v4.0 concepts such as DEs, groups, SHMTIs and TDCF. But another firmware
or control-plane specification could show up later with the same broad
telemetry model and a different wire format. Call it XXMI or YYMI: the
protocol mechanics would differ, but the kernel consumers should not have to
learn a new in-kernel and userspace ABI for each one.

The common ABI should therefore avoid treating the DE numeric namespace or
the wire/storage format as the abstraction. The useful common contract is
closer to:

  - what is being measured: component/type/instance/name;
  - how to interpret it: unit, exponent/rate unit, data width and signedness;
  - how it behaves: instantaneous, accumulating, average, state/counter, etc.;
  - how it is controlled: individual event vs group-wide collection;
  - how fresh it is: timestamp, sequence/generation and validity/error flags.

So I would strongly consider inserting a generic telemetry layer above SCMI,
with SCMI registering as a telemetry provider rather than owning the stable
userspace ABI directly.

Roughly:

  drivers/telemetry/
      provider registration
      descriptor/sample/config abstractions
      generation tracking and poll support
      common userspace ABI

  drivers/firmware/arm_scmi/telemetry.c
      SCMI protocol implementation
      TDCF/SHMTI/notification parsing
      translation into generic telemetry descriptors/samples

  optional provider-private raw/debug path
      SCMI SHMTI mmap or dumps, if kept, behind explicit privilege/debug
      policy rather than as the baseline telemetry ABI

With that shape, future in-kernel consumers could bind to generic telemetry
objects and capabilities instead of SCMI internals. Architected/well-known
DEs could later grow adapters into hwmon/IIO/perf where the semantics are
clear, while platform-specific DEs remain available through the generic
telemetry interface plus userspace metadata.

This would also help avoid making the SCMI protocol's internal resource
storage part of the ABI. Right now the public protocol header exposes
structures such as scmi_telemetry_res_info, scmi_telemetry_group and
scmi_telemetry_de, and the chardev indexes those objects directly. That feels
too tightly coupled for something that may need more consumers later. I would
prefer copy-out or iterator-style provider ops instead, for example:

  info_get()
  de_count_get()
  de_info_get()
  group_info_get()
  intervals_get()
  collection_set()
  collection_get()
  sample_read()
  reset()

where the backing arrays, xarrays, lazy enumeration, SHMTI mappings and TDCF
parsing remain private to the SCMI provider.

The sample side probably needs an explicit common result contract too. A
sample is not only an integer value: it may have optional timestamping,
provider data width, stale/not-yet-valid state, partial collection failures,
hardware-fault indications, and a sequence/generation value that lets
userspace detect races against reconfiguration or shared-memory updates. Those
details can still be backed by SCMI-specific status codes and TDCF parsing
internally, but I think the stable ABI should expose them in provider-neutral
terms.

I would also be careful about freezing the raw SHMTI mmap part as a baseline
ABI. It is useful for bring-up and high-performance tooling, but it exposes
firmware-owned shared memory layout and TDCF parsing rules directly to
userspace. If this stays, I think it should be clearly separated as a
privileged/debug/raw provider facility, with a precise mmap contract:

  - required mmap length
  - vm_pgoff semantics
  - page alignment
  - VMA flags
  - cache/coherency expectations
  - lifetime across reset/remove/reprobe
  - required capability, if any

Even outside the raw mmap case, telemetry can be a sensitive high-rate view
of system behavior. The ABI should make access policy explicit: who can
enumerate, who can read, who can change collection state, and whether
production systems can restrict sampling granularity or intervals
independently of what firmware advertises.

For the stable telemetry ABI, I would start smaller: descriptor enumeration,
sample reads with validity metadata, optional group-aware configuration, and a
generation counter/poll mechanism so userspace can detect reconfiguration or
partial re-enumeration races.

One other point related to this layering: configuration appears to be global
to the SCMI instance. Any process opening /dev/scmi/tlm_N can change
collection mode, sampling interval, DE enablement and timestamp state for
other users. That may be OK, but it should be an explicit policy decision.
A generic telemetry layer could make the model clearer: multi-reader with a
privileged/single writer, or fully shared global controls, with instance-level
locking and generation updates after each visible state change.

So my high-level suggestion for v6 would be:

  1. define the generic telemetry provider/consumer model first;
  2. make SCMI Telemetry one provider of that model;
  3. keep SCMI/TDCF/SHMTI details below the provider boundary;
  4. keep raw SHMTI access separate from the stable ABI;
  5. define common sample validity/freshness/error semantics;
  6. add generation/poll semantics to the common ABI;
  7. make lifetime, access policy and configuration concurrency explicit.

I do not think this invalidates the protocol work in the series. Most of the
SCMI parsing and resource discovery can still be the provider implementation.
The main question is where the stable kernel/userspace contract should sit.
My preference would be that it sits at "telemetry", not at "SCMI Telemetry",
so that SCMI, and any future XXMI/YYMI-style provider, can share one consumer
interface.

Thanks,

Re: [PATCH v5 00/23] Introduce SCMI Telemetry support

[David Hildenbrand (Arm)]

On 7/7/26 08:31, Subrahmanya Lingappa wrote:
> Hi Cristian,

Hi!

Thanks for having a look. Christian is out this week, so let me ask some
clarifying questions and raise some points.

> 
> Thanks for posting this. I think the direction of not forcing these
> Telemetry Data Events into hwmon/IIO/perf prematurely is the right one.

Good.

> The cover letter explains the core problem well: most DE IDs are
> platform-defined, and without external metadata the kernel cannot reliably
> know whether a DE is a thermal sensor, a performance counter, a power value,
> or something entirely platform-specific.

Right.

> 
> That said, I think the current layering is still too SCMI-shaped for the
> ABI it is trying to introduce.

Just to be clear: the data is exposed through /dev/scmi/ device nodes. It is
expected to be very, very SCMI specific as it stands :)

> 
> The thing being exposed here is not only "SCMI Telemetry"; it is a more
> general kernel concept of telemetry:
> 
>   - enumerate provider-specific data/event descriptors
>   - expose capabilities, units, data format and topology/grouping metadata
>   - configure collection rate and collection mode where supported
>   - collect samples with timestamp/freshness/validity information
>   - track generation/state changes
>   - optionally expose provider-private raw backing storage for debugging

Yes, there are some generic concepts there. However, when we talk about
generalizing, I suspect that other telemetry implementations might vary quite
already even on these generic points?

In particular when it comes about enumeration (as discussed previously, some
telemetry solutions might expose way more detailed information about events) and
configurations (and, in particular, things like configuration groups).

But also efficient ways to receive data in user space.

I mean, sure, if someone uses the exact same concept but instead of calling it
SCMI, calls it XXMI, that's one thing.

But a true generic telemetry concept would have to take way more options into
account.

So defining something actual generic and extensible might be rather challenging,
no? And for that, I would expect a pretty good reason to do so.

"Make tool X easier to implement" would not be a good reason in my option. I'm
sure you have something in mind, what would that be?

> 
> SCMI is one provider of that model. It happens to transport the data through
> SCMI v4.0 concepts such as DEs, groups, SHMTIs and TDCF.

Right.

> But another firmware
> or control-plane specification could show up later with the same broad
> telemetry model and a different wire format. Call it XXMI or YYMI: the

"could" is a bit vague. Do you have any concrete examples in mind? It will be
rather challenging to figure out what's generic without other real examples.

> protocol mechanics would differ, but the kernel consumers should not have to
> learn a new in-kernel and userspace ABI for each one.

So far, the tools that consume this data are expected to be very platform specific.

IOW, not your ordinary perf/top/whatever :)

Assuming there is some XXMI telemetry in the future, I would expect tools that
could operate across multiple platforms to build upon some generic user space
library that abstracts these things and knows how to talk to the different devices.

> 
> The common ABI should therefore avoid treating the DE numeric namespace or
> the wire/storage format as the abstraction. The useful common contract is
> closer to:
> 
>   - what is being measured: component/type/instance/name;
>   - how to interpret it: unit, exponent/rate unit, data width and signedness;
>   - how it behaves: instantaneous, accumulating, average, state/counter, etc.;
>   - how it is controlled: individual event vs group-wide collection;
>   - how fresh it is: timestamp, sequence/generation and validity/error flags.
> 
> So I would strongly consider inserting a generic telemetry layer above SCMI,
> with SCMI registering as a telemetry provider rather than owning the stable
> userspace ABI directly.

Again, I think that's rather hard. And it's not immediately clear to me why this
abstraction must be had in the kernel, instead of in user space?

So it would be good if you could elaborate on that.

> 
> Roughly:
> 
>   drivers/telemetry/
>       provider registration
>       descriptor/sample/config abstractions
>       generation tracking and poll support
>       common userspace ABI

That will be a struggle to define in a future-proof way I'm afraid.

> 
>   drivers/firmware/arm_scmi/telemetry.c
>       SCMI protocol implementation
>       TDCF/SHMTI/notification parsing
>       translation into generic telemetry descriptors/samples
> 
>   optional provider-private raw/debug path
>       SCMI SHMTI mmap or dumps, if kept, behind explicit privilege/debug
>       policy rather than as the baseline telemetry ABI

That makes the SCMI SHMTI mmap interface a second-class citizen, which IIUC is
rather bad performance wise.

> 
> With that shape, future in-kernel consumers could bind to generic telemetry
> objects and capabilities instead of SCMI internals. Architected/well-known
> DEs could later grow adapters into hwmon/IIO/perf where the semantics are
> clear, while platform-specific DEs remain available through the generic
> telemetry interface plus userspace metadata.
> 
> This would also help avoid making the SCMI protocol's internal resource
> storage part of the ABI. Right now the public protocol header exposes
> structures such as scmi_telemetry_res_info, scmi_telemetry_group and
> scmi_telemetry_de, and the chardev indexes those objects directly. That feels
> too tightly coupled for something that may need more consumers later. I would
> prefer copy-out or iterator-style provider ops instead, for example:
> 
>   info_get()
>   de_count_get()
>   de_info_get()
>   group_info_get()
>   intervals_get()
>   collection_set()
>   collection_get()
>   sample_read()
>   reset()
> 
> where the backing arrays, xarrays, lazy enumeration, SHMTI mappings and TDCF
> parsing remain private to the SCMI provider.
> 
> The sample side probably needs an explicit common result contract too. A
> sample is not only an integer value: it may have optional timestamping,
> provider data width, stale/not-yet-valid state, partial collection failures,
> hardware-fault indications, and a sequence/generation value that lets
> userspace detect races against reconfiguration or shared-memory updates. Those
> details can still be backed by SCMI-specific status codes and TDCF parsing
> internally, but I think the stable ABI should expose them in provider-neutral
> terms.
> 
> I would also be careful about freezing the raw SHMTI mmap part as a baseline
> ABI. It is useful for bring-up and high-performance tooling, but it exposes

Correct me if I'm wrong: most user space tools we expect will fall into the
category of "high-performance tooling"?

Or which tools do you have in mind that have different requirements?

> firmware-owned shared memory layout and TDCF parsing rules directly to
> userspace. If this stays, I think it should be clearly separated as a
> privileged/debug/raw provider facility, with a precise mmap contract:
> 
>   - required mmap length
>   - vm_pgoff semantics
>   - page alignment
>   - VMA flags
>   - cache/coherency expectations
>   - lifetime across reset/remove/reprobe
>   - required capability, if any
> 
> Even outside the raw mmap case, telemetry can be a sensitive high-rate view
> of system behavior. The ABI should make access policy explicit: who can
> enumerate, who can read, who can change collection state, and whether
> production systems can restrict sampling granularity or intervals
> independently of what firmware advertises.
> 
> For the stable telemetry ABI, I would start smaller: descriptor enumeration,
> sample reads with validity metadata, optional group-aware configuration, and a
> generation counter/poll mechanism so userspace can detect reconfiguration or
> partial re-enumeration races.
> 
> One other point related to this layering: configuration appears to be global
> to the SCMI instance. Any process opening /dev/scmi/tlm_N can change
> collection mode, sampling interval, DE enablement and timestamp state for
> other users. That may be OK, but it should be an explicit policy decision.
> A generic telemetry layer could make the model clearer: multi-reader with a
> privileged/single writer, or fully shared global controls, with instance-level
> locking and generation updates after each visible state change.
> 
> So my high-level suggestion for v6 would be:
> 
>   1. define the generic telemetry provider/consumer model first;
>   2. make SCMI Telemetry one provider of that model;
>   3. keep SCMI/TDCF/SHMTI details below the provider boundary;
>   4. keep raw SHMTI access separate from the stable ABI;
>   5. define common sample validity/freshness/error semantics;
>   6. add generation/poll semantics to the common ABI;
>   7. make lifetime, access policy and configuration concurrency explicit.
> 
> I do not think this invalidates the protocol work in the series. Most of the
> SCMI parsing and resource discovery can still be the provider implementation.
> The main question is where the stable kernel/userspace contract should sit.
> My preference would be that it sits at "telemetry", not at "SCMI Telemetry",
> so that SCMI, and any future XXMI/YYMI-style provider, can share one consumer
> interface.

Again, I'd like to understand why you think this abstraction should be had in
the kernel, when it could also be had in user space. I'm sure there is a good
reason you have in mind.

In particular, I am curious about tools you would expect to run across platforms
that would even care about this.

Last but not least, which other telemetry implementations do you have in mind
that are on the horizon?

In particular, I'm afraid a generic abstraction in the kernel for a handful of
specialized user space tools might take a rather long time to flesh out.

Finally, I wonder if something generic is really required when talking about an
ioctl interface. I would completely agree if we would be talking about something
like resctl, that actually exposes the data to user space in an abstracted,
easy-to-use fashion -- not just an ioctl interface to talk to a device

Thanks for taking the time to write all this up. I'll have to leave all the SCMI
details to Christian!

-- 
Cheers,

David

Re: [PATCH v5 00/23] Introduce SCMI Telemetry support

[Cristian Marussi]

On Tue, Jul 07, 2026 at 12:01:37PM +0530, Subrahmanya Lingappa wrote:
> Hi Cristian,

Hi,

I will add a few considerations here aside the main points highlighed
already by David in this thread.
 
> 
> Thanks for posting this. I think the direction of not forcing these
> Telemetry Data Events into hwmon/IIO/perf prematurely is the right one.
> The cover letter explains the core problem well: most DE IDs are
> platform-defined, and without external metadata the kernel cannot reliably
> know whether a DE is a thermal sensor, a performance counter, a power value,
> or something entirely platform-specific.
> 
> That said, I think the current layering is still too SCMI-shaped for the
> ABI it is trying to introduce.
> 

well... "Introduce SCMI Telemetry" seems a pretty much telling $SUBJECT :P

> The thing being exposed here is not only "SCMI Telemetry"; it is a more
> general kernel concept of telemetry:
> 
>   - enumerate provider-specific data/event descriptors
>   - expose capabilities, units, data format and topology/grouping metadata
>   - configure collection rate and collection mode where supported
>   - collect samples with timestamp/freshness/validity information
>   - track generation/state changes
>   - optionally expose provider-private raw backing storage for debugging
> 
> SCMI is one provider of that model. It happens to transport the data through
> SCMI v4.0 concepts such as DEs, groups, SHMTIs and TDCF. But another firmware
> or control-plane specification could show up later with the same broad
> telemetry model and a different wire format. Call it XXMI or YYMI: the
> protocol mechanics would differ, but the kernel consumers should not have to
> learn a new in-kernel and userspace ABI for each one.
> 

So, in the early episodes of this Telemetry 'saga' when it still was an
RFC [1] in which I was exploring/experimenting/evaluating different approaches
I DID mention that one possible evolutions of whatever interface would have been
used (SysFS vs chardev vs FileSystem) could have been:

"D. generalize enough one of the above choices to make it abstract enough        
   that other non-SCMI based telemetry can plug into some sort of geenric       
   Telemetry subsystem"

...BUT the reality check that immediately stopped this possibility onto
his tracks for me was the fact that at that time, like now, there was/is
ONLY the SCMI protocol acting as a possible Telemetry provider so that would
have meant:

 1. limited real use case examples to use to build a common Telemetry abstraction
    resulting most probably in a 'generic' common framework heavily
    biased toward SCMI mechanisms...for the simple fact that only SCMI really
    existed that provided such broad range of generic telemetry data....

 2. sure rejection from upstream, having created a supposedly generic common
    framework, sadly used by....just ONLY one user

These concerns came on top of the basic main fact that, as David pointed out,
a fully generic and common abstraction of Telemetry concepts is hard...

...it definitely seems easy at first by looking at some basic simple
common ideas, but it quickly becomes very challenging to represent in a
common way very speficic bits like, as an example, topology, grouping
etc etc ...and again especially when you have ONLY one user of this new
abstraction to look at for inspiration ...

> The common ABI should therefore avoid treating the DE numeric namespace or
> the wire/storage format as the abstraction. The useful common contract is
> closer to:
> 
>   - what is being measured: component/type/instance/name;
>   - how to interpret it: unit, exponent/rate unit, data width and signedness;
>   - how it behaves: instantaneous, accumulating, average, state/counter, etc.;
>   - how it is controlled: individual event vs group-wide collection;
>   - how fresh it is: timestamp, sequence/generation and validity/error flags.
> 
> So I would strongly consider inserting a generic telemetry layer above SCMI,
> with SCMI registering as a telemetry provider rather than owning the stable
> userspace ABI directly.
> 
> Roughly:
> 
>   drivers/telemetry/
>       provider registration
>       descriptor/sample/config abstractions
>       generation tracking and poll support
>       common userspace ABI
> 
>   drivers/firmware/arm_scmi/telemetry.c
>       SCMI protocol implementation
>       TDCF/SHMTI/notification parsing
>       translation into generic telemetry descriptors/samples
> 
>   optional provider-private raw/debug path
>       SCMI SHMTI mmap or dumps, if kept, behind explicit privilege/debug
>       policy rather than as the baseline telemetry ABI
> 
> With that shape, future in-kernel consumers could bind to generic telemetry
> objects and capabilities instead of SCMI internals. Architected/well-known
> DEs could later grow adapters into hwmon/IIO/perf where the semantics are
> clear, while platform-specific DEs remain available through the generic
> telemetry interface plus userspace metadata.
> 
> This would also help avoid making the SCMI protocol's internal resource
> storage part of the ABI. Right now the public protocol header exposes
> structures such as scmi_telemetry_res_info, scmi_telemetry_group and

Well here you are mentioning the SCMI internal API as exposed by the SCMI
core in include/linux/scmi_protocol.h and used by SCMI drivers to build
on top of the common protocol layer...of course it is SCMI specific,
always will be, even when/if a common Telemetry framework would exist.

> scmi_telemetry_de, and the chardev indexes those objects directly. That feels
> too tightly coupled for something that may need more consumers later. I would
> prefer copy-out or iterator-style provider ops instead, for example:
> 
>   info_get()
>   de_count_get()
>   de_info_get()
>   group_info_get()
>   intervals_get()
>   collection_set()
>   collection_get()
>   sample_read()
>   reset()
> 
> where the backing arrays, xarrays, lazy enumeration, SHMTI mappings and TDCF
> parsing remain private to the SCMI provider.

I could agree on this...IF any of this would have a chance to exist now
with the current existing Telemetry providers...thing that seems not
plausible for the reasons above....

> 
> The sample side probably needs an explicit common result contract too. A
> sample is not only an integer value: it may have optional timestamping,
> provider data width, stale/not-yet-valid state, partial collection failures,
> hardware-fault indications, and a sequence/generation value that lets
> userspace detect races against reconfiguration or shared-memory updates. Those
> details can still be backed by SCMI-specific status codes and TDCF parsing
> internally, but I think the stable ABI should expose them in provider-neutral
> terms.

Yes some of these are theoretically possible, but NOT really in the only 
example we have so far that is SCMI....

> 
> I would also be careful about freezing the raw SHMTI mmap part as a baseline
> ABI. It is useful for bring-up and high-performance tooling, but it exposes
> firmware-owned shared memory layout and TDCF parsing rules directly to
> userspace. If this stays, I think it should be clearly separated as a
> privileged/debug/raw provider facility, with a precise mmap contract:
> 
>   - required mmap length
>   - vm_pgoff semantics
>   - page alignment
>   - VMA flags
>   - cache/coherency expectations
>   - lifetime across reset/remove/reprobe
>   - required capability, if any

I would also prefer to expose only kernel mediated Telemetry data to
avoid fragmentation (even within the same protocol when implemented by
different vendors...), BUT RAW access I am afraid is inevitable to be
able to write high-perf tools, and those will have necessarily to be
protocol/backend specific...

...which leads straight to the other point raised by David...

...Is really a common Telemetry UAPI needed ?

...if anyway multiple protocols would dictate multiple custom tools
probably not...

> Even outside the raw mmap case, telemetry can be a sensitive high-rate view
> of system behavior. The ABI should make access policy explicit: who can
> enumerate, who can read, who can change collection state, and whether
> production systems can restrict sampling granularity or intervals
> independently of what firmware advertises.
>

Yes this has defintely to be documented better...but..

..this is something again very much protocol specific, that evidentiates
once more that a common ABI to rule them all is not probably the way...

...in SCMI the platform firmware is the ultimate arbiter, it is in charge
of any kind of policying...it can cope even with the most unreasonable
asks coming from the agents, even come from root privileged users...

...simply because those requests will get denied OR silently ignored...

...in the case of SCMI Telemetry, as an example, it is up to the server expose
to the Linux Agent ONLY what it deems to be safe enough to be shared with normal
world entities without the risk of enabling side channel attacks...

IOW, in the SCMI world, in any protocol, the agents see and live in an
illusion that is created and enforced by the SCMI server, if you are
switching your point of view and start considering how to enforce policies
around SCMI resources at the agent level ("...only root will be able to do
that"), you are already doing it wrong...

Can this view of the platform be absracted, Telemetry-wise, in a common
interface across any other protocol and any other arch ?

It seems to me, again, very unlikely...

> For the stable telemetry ABI, I would start smaller: descriptor enumeration,
> sample reads with validity metadata, optional group-aware configuration, and a
> generation counter/poll mechanism so userspace can detect reconfiguration or
> partial re-enumeration races.
> 
> One other point related to this layering: configuration appears to be global
> to the SCMI instance. Any process opening /dev/scmi/tlm_N can change
> collection mode, sampling interval, DE enablement and timestamp state for
> other users. That may be OK, but it should be an explicit policy decision.

Based on the SCMI architecture and the SCMI implementation in Linux, the
only boundary that you can use to identify a 'user' is am SCMI instance
(i.e. one /dev/scmi/tlm_<N>) because that is what the server(s) on the other
side can identify as a distinct agent and that it can fed with a well defined
set of resources at enumeration time...especially in the case of Telemetry
it seems dificult to be able to partition resources at the agent side...

As it was with the defunct Filesyste approach, I would NOT in general
enfore any policy on configuration...last config request will win PLUS
a generation counter to spot unexpected reconfig happening in background...

If you are using 2 tools or daemons to configure telemetry on the same
system in a conflicting way, it is NONE of kernel businness, you have a
misconfigured platform..

Last but NOT least, I think that maybe a Telemetry framework subsystem
could be instead useful for future possible in-kernel users of Telemetry
(you may have mentioned that too..) ... should someone decide to use this
type of data in-kernel, it would certainly be useful to a have common
in-kernel API to consume these data no matter which is the provider from
which that data is collected...

...BUT, again, in this case we do NOT even have a single user as of now
to model this intefrcae against, since we are currently NOT using SCMI
Telemetry for that...so it is seems even more a remote/impossible thing
to get something like this upstream for now...

Thanks,
Cristian

[1]: https://lore.kernel.org/arm-scmi/20250620192813.2463367-1-cristian.marussi@arm.com/