Speaker
Description
Background
Automotive and embedded virtualization stacks increasingly run Android(AAOS) or Linux as a GuestVM that needs access to platform infrastructure -- clocks and regulators -- managed by a host or
hypervisor. The upstream Linux kernel provides a complete guest-side solution for this via SCMI-over-virtio: clk-scmi (upstream since v4.17), scmi-regulator, and the SCMI virtio transport (upstream since v5.15) are all mainlined, including atomic/polling mode support for noirq contexts.
However, no open-source host-side virtio backend implements the SCMI clock or voltage/regulator protocols today. This gap forces vendor BSPs into non-standard workarounds that conflict with upstream.
Motivation
This topic originates from a real failure observed on a vendor GuestVM BSP where clock and regulator providers were implemented directly on top of virtio-mmio, bypassing SCMI. These providers require noirq PM callbacks, but virtio-mmio is fundamentally IRQ-dependent and was never designed with noirq semantics. The BSP forces the entire virtio-mmio bus into noirq mode as a workaround, which breaks other devices on the same bus -- virtio-blk loses its IRQ during suspend and the system hangs.
An RFC v9 [1] was posted to add opt-in noirq PM callbacks to virtio-mmio. Through the review process, it became clear that the root cause is not a missing feature in virtio-mmio, but the absence of the SCMI host backend that would make the standard path viable for vendors. No upstream virtio device requires noirq operation, and the upstream-intended path for virtualizing platform infrastructure is SCMI-over-virtio, not direct virtio-mmio drivers.
Current State of the Host-Side Ecosystem
- rust-vmm/vhost-device-scmi [3] (Linaro) -- Provides a virtio backend framework but only implements the base and sensor protocols. Clock and voltage/regulator are not supported.
- Qualcomm kernel vhost-scmi [2] -- RFC v1 posted June 2022, included clock and voltage backends. No v2 was submitted; effectively abandoned.
- crosvm vhost-scmi (Qualcomm) -- VMM-level plumbing referencing the Qualcomm kernel backend. Does not include standalone protocol handling.
- SCP-firmware [4] / OP-TEE -- Production-quality SCMI servers with full clock and voltage support, but run on dedicated SCP hardware or TEE, not as virtio backends.
The building blocks exist on both sides -- SCP-firmware has mature
protocol handlers, and vhost-device-scmi has the virtio backend
framework -- but nobody has connected them.
Discussion Topics
(1) Status of ongoing efforts.
Is the host backend gap recognized within the AAOS and Linaro communities? Are there ongoing efforts to add clock/voltage protocol support to vhost-device-scmi or an equivalent that are not publicly visible?
(2) Ownership and collaboration model.
Connecting SCP-firmware's protocol handlers with vhost-device-scmi's framework seems tractable. Should this be driven by Linaro, by SoC vendors, or as a cross-organizational effort?
(3) Interim safety measures.
BSPs that ship virtio-mmio-based clock/regulator implementations cannot migrate to SCMI overnight.
Left unaddressed, vendors are likely to carry downstream patches that force virtio-mmio into noirq mode in unsafe ways -- breaking other devices on the same bus or causing hard-to-reproduce hangs in the field.
Leaving this entirely to downstream carries real risk: each vendor will independently hack virtio-mmio's PM path without adequate timeout handling or error recovery, and the same class of bugs will repeat across vendors.
Should upstream add defensive measures, such as runtime detection of noirq misuse in virtio-mmio (warn and abort suspend rather than hang), explicit documentation that virtio-mmio is not suitable for noirq devices, or probe-time rejection of drivers that declare noirq requirements on virtio-mmio?
What practical barriers exist for migrating to SCMI-over-virtio, and what is a realistic timeline?
(4) Documenting the recommended path.
The recommendation to use SCMI-over-virtio for GuestVM platform infrastructure is currently implicit. Documenting it explicitly would prevent future vendors from repeating the non-standard pattern.
Why the Android MC
This problem sits at the intersection of SCMI maintainers (ARM), rust-vmm/vhost-device maintainers (Linaro), Android/AAOS virtualization teams (Google, Qualcomm), and virtio maintainers. None of them can close the gap alone. The Android MC brings these communities together, and AAOS virtualization is the primary use case driving this need.
References
- [1] RFC v9: virtio noirq PM callbacks -- https://lore.kernel.org/lkml/20260516015756.20948-1-baver.bae@gmail.com/
- [2] Qualcomm SCMI Vhost RFC (2022) -- https://lwn.net/Articles/897389/
- [3] rust-vmm/vhost-device-scmi -- https://github.com/rust-vmm/vhost-device/tree/main/vhost-device-scmi
- [4] ARM SCP-firmware -- https://github.com/ARM-software/SCP-firmware
- [5] SCMI virtio transport (upstream) -- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/arm_scmi/virtio.c
- [6] clk-scmi driver (upstream) -- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/clk-scmi.c
- [7] Linaro blog: Rust device backends -- https://www.linaro.org/blog/rust-device-backends-for-every-hypervisor/
- [8] AAOS virtualization architecture -- https://source.android.com/docs/automotive/virtualization