Mixed-Criticality Scheduling on Shared SoCs: Why VM Partitioning Alone Isn’t Enough
Quick Overview
Problem: Static VM partitioning enforces spatial memory isolation between ASIL and QM workloads. It does not, on its own, control temporal contention in the shared last-level cache, DRAM controller, or accelerator submission path.
Common failure points: WCET margin evaporates under LLC eviction from a QM neighbour, DRAM request latency drifts under GPU or ISP bursts, interrupt latency drifts on shared GIC routing, accelerator submissions from a QM guest delay safety-relevant work.
Where it appears: Cortex-A cockpit domain controllers, ADAS + cockpit consolidation platforms, industrial safety-plus-vision controllers, medical monitor-plus-display systems.
Engineering focus: Cache coloring in the hypervisor allocator, memory-controller QoS bandwidth control, hierarchical scheduling servers, mediated GPU/NPU submission with priority, and — where appropriate — ASIL decomposition into a redundant safety monitor.
Production Failure Scenario
Wrong Assumption
Why It Fails
Shared last-level cache is a hidden interference channel. Cortex-A55/A78 clusters and comparable application-processor SoCs share an L2 or L3 last-level cache (LLC) across cores. A QM multimedia pipeline decoding a high-resolution frame occupies a substantial fraction of that LLC. When an ASIL control task runs next, its working set has been evicted, and it experiences cache misses that were not present in the isolated WCET measurement. Because the eviction happens in hardware-managed cache logic, it does not cross a VM boundary — the hypervisor cannot observe or enforce against it directly. Arm’s own MPAM specification addresses this by exposing hardware controls for cache partitioning and memory bandwidth; where MPAM is not implemented, software page-coloring in the hypervisor provides an equivalent path.
DRAM controller contention silently extends memory-access latency. GPU rendering, ISP writes, NPU tensor loads, and the ASIL task’s memory reads all queue at the shared DRAM controller. A GPU burst can delay the ASIL partition’s memory requests by the queuing time inside the controller — again, extending execution time past the WCET bound. Mitigation uses the memory controller’s hardware QoS registers, documented on NXP i.MX 8M, TI TDA4VM, and comparable SoCs. Software-only bandwidth policies (a QM app voluntarily throttling itself) are not adequate as ASIL-D FFI evidence. The broader case for enforcing these boundaries inside the hypervisor sits in the secure partitioning in automotive hypervisors discussion.
Accelerator submission is a shared resource without native priority. GPU passthrough gives one VM sole ownership, which forfeits consolidation. Mediated passthrough shares the accelerator, but the submission queue needs a hypervisor-side priority scheduler so that safety submissions overtake QM submissions at dispatch. Certification scope for shared GPU/NPU execution is platform- and release-specific — the safety case has to be checked against the vendor’s Safety Manual, the supported virtualization configuration, and the exact accelerator path used by the safety function. Qualcomm’s Snapdragon Ride Flex and NVIDIA’s DriveOS/Halos programs both describe mixed-criticality architectures with hypervisor isolation and safety-rated compute paths; what each program certifies, and for which release, needs to be read from the current Safety Manual rather than assumed. This is where the hypervisor architecture decision in software-defined vehicles meets the shared-accelerator problem.
Interrupt latency is only partly partitioned. On processors without full interrupt virtualization support, an interrupt that fires during a QM VM’s timeslice can be handled with QM-partition latency instead of ASIL latency — a determinism drift that does not require any explicit interference between workloads, only that they run on the same physical GIC.
Hidden System Complexity
Failure Patterns
The scenarios below describe common integration-phase patterns; they are illustrative rather than tied to a specific program.
Scenario 1. A cockpit domain controller runs an ASIL-B instrument cluster and a QM Android infotainment stack on the same Cortex-A cluster with an ASIL-assessed hypervisor. Isolated cluster benchmarks meet a 60 fps rendering budget. Under production load — active navigation, 4K video decode, Bluetooth audio, and telltale animations — a measurable fraction of cluster frames overrun frame time. The LLC working set of the video decoder is evicting cluster rendering state; the fix is cache coloring in the hypervisor page allocator, not a faster GPU.
Scenario 2. An ADAS SoC shares a DRAM controller between an ASIL perception task and a QM navigation renderer. Bench measurements of the perception task pass the timing budget with margin. Under concurrent map-tile streaming, the perception task’s memory latency rises and a small fraction of frames miss the deadline. The DRAM controller exposes QoS registers, but none were configured — the architecture-phase assumption was that VM partitioning covered memory isolation. It didn’t.
Scenario 3. A safety-plus-visualization industrial controller shares an NPU between an ASIL anomaly-detection model and a QM operator-facing analytics dashboard. Both models run inside their measured latency in isolation. Concurrently, dashboard inferences push submission queue depth up, and the safety inference misses its deadline sporadically — correlated with operator interaction, not with machine state.
Mixed-Criticality ECU and Platform Engineering
Mixed-criticality behaviour on shared-SoC platforms is rarely a schedulability problem. It shows up as unbounded LLC eviction, unconfigured memory-controller QoS, and accelerator submission paths without priority mediation — invisible in single-partition testing, visible only under production multimedia and safety workloads running together. Promwad works with automotive and industrial customers on ECU software, Qualcomm/QNX/Linux/AAOS BSP integration, ASPICE CL2 delivery, and ISO 26262 support up to ASIL C, and can advise on the architecture-phase choices that make an ASIL-D consolidation program tractable.
Engineering Experience Across Automotive Compute Platforms
A Cockpit Domain Controller Where Isolated Timing Passed and Integrated Timing Didn’t
A typical cockpit consolidation program targets a high-performance Cortex-A SoC — an ASIL-B instrument cluster in one VM, a QM Android Automotive infotainment stack in another, both scheduled by an ASIL-assessed hypervisor with dedicated cores per partition, MMU-enforced memory partitions, and a shared GPU under mediated passthrough. Isolated bring-up on each partition meets every timing budget, and initial short-integration tests look clean.
Extended integration under production video load surfaces two patterns. Cluster frame rate degrades whenever the infotainment side decodes 4K video, and the degradation tracks LLC utilization on the QM partition — not GPU load, and not CPU load on the cluster side. Separately, GPU submission latency for time-critical cluster telltales varies with Android UI activity, beyond what the hypervisor’s advertised submission priority would predict.
Two mechanisms address the two problems. LLC eviction is closed with cache coloring in the hypervisor page allocator — the ASIL cluster partition gets a reserved LLC region that the QM workload cannot evict. GPU submission jitter is closed with a hypervisor-side priority queue in front of the mediated passthrough path, so ASIL submissions overtake QM submissions at dispatch. Neither requires a silicon respin or a hypervisor swap; both require characterising the SoC’s LLC set-index mapping and reworking the accelerator submission path inside the hypervisor. The safety-case update against ISO 26262 Part 6 is a follow-on document set, not a re-validation of the underlying software.
This is a representative pattern — not a specific delivered program. The point is that the mechanisms exist, and that they belong in the architecture phase rather than the integration phase.
Solution Approach
Step 1: Turn temporal interference at the cache into spatial partitioning. Cache coloring in the hypervisor memory allocator assigns non-overlapping LLC set regions to each partition by controlling the physical page addresses granted to each guest. Because the LLC is indexed by a subset of the physical address bits, pages allocated in different “colors” cannot evict each other, regardless of access pattern. Prerequisites are knowledge of the SoC’s LLC set-index-to-physical-address mapping (SoC-specific, typically needs measurement or vendor documentation) and a page allocator that honors color constraints. On Arm application processors, Bao and Jailhouse implement this pattern in the open source space; on Intel/x86 platforms, ACRN uses Intel RDT/CAT for shared-cache partitioning. Several proprietary automotive hypervisors expose equivalent mechanisms in their safety-oriented configurations. Cache coloring converts an unbounded temporal-interference channel into a bounded, hardware-enforced spatial partition, and can form part of the technical evidence supporting the FFI argument at ASIL D — sufficiency in a given program is decided by the safety concept, the SoC, and the validation evidence, not by the mechanism alone.
Step 2: Bound DRAM bandwidth per requester in the memory controller. Configure the memory-controller QoS registers to protect the ASIL partition’s request-latency budget under worst-case QM traffic, either by capping the GPU/ISP/NPU maximum bandwidth or by raising the ASIL partition’s priority class. On NXP i.MX 8M and TI TDA4VM-class SoCs the registers are documented and per-master. On others, this step includes characterising the master-ID assignment and validating the effective bandwidth ceiling with measurement — the QoS setting is only meaningful once verified against a produced traffic mix.
Step 3: Mediate accelerator submission with priority. GPU or NPU passthrough gives one partition sole use of the accelerator, which forfeits consolidation. Mediated passthrough shares the accelerator, but the submission queue needs a hypervisor-side priority scheduler so that safety submissions overtake QM submissions at dispatch. Where the safety concept requires ASIL-D coverage on the accelerator path itself, the practical routes today are either (a) ASIL decomposition into two ASIL-B channels with a redundant safety monitor, (b) restricting the ASIL-D function to a code path that does not use the shared accelerator, or (c) selecting a platform whose Safety Manual explicitly covers the accelerator sharing configuration you intend to use. The redundant-channel route is covered in the safety island design and ASIL decomposition discussion.
Cache and DRAM interference are typically the two channels that survive a “VMs only” architecture into integration. Closing them early — before the safety case is written against a WCET margin that hasn’t been measured under mixed load — is usually cheaper than closing them under integration-phase pressure.
Real Trade-Offs
Reserving an LLC partition to the ASIL VM through cache coloring gives the safety task deterministic cache behaviour but shrinks the effective LLC for the QM multimedia pipeline. On an 8 MB L3, a 2 MB ASIL reservation removes a quarter of the cache the video decoder was relying on; the QM performance impact has to be characterised and accepted in the platform budget.
Capping GPU DRAM bandwidth in the memory controller protects the ASIL partition’s memory-latency budget but forces the QM path to render at a lower texture rate or a reduced frame size. For a cluster + infotainment consolidation, that trade-off is usually acceptable; for a heavier infotainment build with 4K decode plus 3D navigation, it can force a codec bitrate cut.
Certification scope for ASIL-D execution on a shared high-performance SoC depends on the specific hypervisor, GPU/NPU stack, and configuration. Where the vendor Safety Manual does not cover the accelerator sharing path you need, ASIL decomposition into two ASIL-B channels — one on the shared SoC, one on a Cortex-R52 lockstep safety monitor — is a well-understood route, at the cost of additional silicon and a cross-monitor communication path. The decomposition-versus-single-part trade-off is a specific case of the broader functional safety versus conventional hardware design argument at the SoC boundary.
The choice of automotive-qualified hypervisor is not homogeneous. Elektrobit ships EB tresos Safety OS up to ASIL D and EB corbos Hypervisor at ASIL B — they cover different parts of the stack. QNX Hypervisor for Safety is assessed against ISO 26262 ASIL D, with supported configurations and safety-relevant constraints documented in its Safety Manual per release. Each choice has to be validated against the specific SoC, the accelerator sharing model, and the ASIL scope; there is no single “certified hypervisor” that pre-covers every mixed-criticality architecture.
Consolidating multiple ECUs onto one high-performance SoC — the cost saving that software-defined vehicle programs were built to capture — only realises the saving once the interference channels are closed. A consolidated ECU that misses its ASIL timing budget under production load is more expensive than the two ECUs it replaced, once debug cycles and safety-case rework are counted.
Typical Mixed-Criticality Engineering Tasks
Interference Characterisation on Target Silicon
Measuring LLC set-index mapping, DRAM controller queuing under multi-master load, and accelerator submission latency under mixed QM + ASIL workloads on the actual production SoC.
Cache Coloring and Hypervisor Allocator Integration
Extending or configuring the hypervisor’s memory allocator to honor color constraints per partition, and validating the coloring against the SoC’s cache set indexing.
Memory-Controller QoS Configuration and Validation
Setting per-master bandwidth and priority policies, measuring effective request-latency bounds under production traffic mixes, and integrating the settings into the platform boot flow.
Mediated Accelerator Submission and Priority Scheduling
Placing a priority-aware submission scheduler between the hypervisor’s accelerator device model and the guest submission queue, and validating dispatch order under contention.
Safety Concept Advisory for Shared-SoC Programs
Scoping ASIL decomposition, safety-monitor integration, and the boundary between what the shared SoC can carry at what ASIL and what belongs on a dedicated lockstep monitor.
Qualifying Symptoms
- ASIL task WCET margin measured on the isolated partition disappears when the QM VM runs at production intensity.
- Cluster or telltale rendering meets its budget in isolation and degrades under concurrent 4K decode on the QM VM, correlated with QM LLC utilization rather than GPU load.
- Memory-controller QoS registers are documented in the SoC reference manual but were not configured in the platform boot flow.
- The hypervisor’s assessment covers spatial isolation and scheduling but does not name cache or DRAM temporal isolation.
- GPU or NPU submission latency for safety-relevant frames varies with QM UI activity.
- ISO 26262 Part 6 safety-case sign-off is blocked on temporal-interference evidence that isolation testing alone cannot produce.
Solution Context Link
The work at this point is temporal-isolation engineering on the target SoC — cache coloring, memory-controller QoS, mediated accelerator submission — and a safety-case rebuild that names these mechanisms in the FFI evidence. Practically, this sits inside ECU and embedded platform design rather than inside a broader hypervisor licence conversation.
For a cockpit or ADAS consolidation, SoC and hypervisor selection interact with the software-defined vehicle programme’s decomposition strategy, and safety-case documentation with the ASPICE software engineering traceability that ties vehicle-level requirements down to hypervisor configuration values. Where the accelerator path is what needs ASIL coverage, the safety island design and ASIL decomposition discussion covers the redundant-channel route.
Promwad Micro Proof
Promwad’s disclosed automotive work covers ECU and platform software, Qualcomm/QNX/Linux/AAOS BSP integration, ASPICE CL2 delivery, and ISO 26262 support up to ASIL C. The mixed-criticality architecture discussion above sits above that — in the architecture and safety-concept phase where SoC, hypervisor, safety-monitor, and decomposition choices are made against the vehicle’s ASIL and QoS budgets. Programs typically benefit from this analysis before the hardware is fixed.
FAQ
Why does VM partitioning not, on its own, solve mixed-criticality on shared application processors?
What is cache coloring and how does it support the ISO 26262 Part 6 argument at ASIL D?
When is ASIL decomposition the more practical answer than pursuing full ASIL D on a shared SoC?
Which hypervisor and safety-OS options should a shared-SoC program consider today?
Related Engineering Cases
- Software Development for an IVI System (ASPICE CL2): In-vehicle infotainment software delivered under ASPICE CL2 process on Qualcomm SA8155 with QNX and Linux — directly relevant to cockpit-consolidation programs where infotainment sits alongside safety-relevant cluster software.
- In-Vehicle Infotainment Simulator with Qualcomm: IVI simulator development on Qualcomm-class silicon — relevant to Cortex-A cockpit consolidation programs.
- ASIL-C High-Accuracy Current Sensor Design: ASIL-C sensor firmware and hardware — an example of safety-rated firmware delivery under ISO 26262 constraints.