Multi-OS Layout on the SoC

Advanced10 min read

Assumes: 5.3 Hypervisor & Virtual Machines

TL;DR

A typical Qualcomm cockpit SoC runs QNX as the hypervisor host on vCPU 0–1, AAOS as a guest on vCPU 2–5, and optionally Linux on vCPU 6–7, all on shared Kryo cores under QHEE at EL2. TrustZone sits at EL3, owning secure keys and crypto. AMSS does NOT run as a VM. It executes on a separate modem processor (baseband subsystem) with its own cores, RTOS, and boot chain. Confusing “modem” with “another Linux VM” is a common integration mistake.

Your daily world spans QNX logs, adb shell, and AMSS crash dumps: three different operating environments on one chip package. This page is the seating chart. It’s the most expensive apartment building you’ll ever debug.

ARM Exception Levels: EL0–EL3

ARM AArch64 defines four privilege rings, Exception Levels (EL):

Level	Name	Who Runs Here	Analogy
EL0	User space	Apps, services, adb shell commands	Tenants doing their jobs
EL1	OS kernel	QNX microkernel, Linux (AAOS), guest kernels	Apartment lease holders
EL2	Hypervisor	QHEE: VM management, stage-2 MMU	Building manager
EL3	Secure Monitor	TrustZone: keys, secure boot, SMC dispatch	Bank vault in the basement

Higher EL = more privilege. A trap up happens on sensitive operations; the lower level requests service, never grabs keys directly.

Count down from the vault: EL3 is TrustZone at the top, EL2 is the hypervisor, EL1 is the kernel, EL0 is user apps.

flowchart TB
    subgraph EL3["EL3 — Secure Monitor"]
        TZ["TrustZone<br/>Keys · Crypto · Secure Boot"]
    end

    subgraph EL2["EL2 — Hypervisor"]
        QHEE["QHEE<br/>VM isolation · Scheduling"]
    end

    subgraph EL1["EL1 — Guest Kernels"]
        QNXK["QNX Kernel<br/>(Host VM)"]
        LINX["Linux Kernel<br/>(AAOS Guest)"]
        LINK["Linux Kernel<br/>(Optional ADAS VM)"]
    end

    subgraph EL0["EL0 — User Space"]
        QNXS["QNX Services<br/>Gateway · Screen · Audio"]
        AND["Android Framework<br/>Apps · VHAL · CarService"]
        LINS["Linux Daemons<br/>Logging · CV pipeline"]
    end

    TZ -->|"SMC calls"| QHEE
    QHEE --> QNXK
    QHEE --> LINX
    QHEE --> LINK
    QNXK --> QNXS
    LINX --> AND
    LINK --> LINS

Mental Model

Picture a high-rise with a basement vault. EL3 (TrustZone) is the vault — only secure monitor code enters. EL2 (QHEE) is the building superintendent’s office — sees all floors, controls access. EL1 floors are separate companies (QNX Corp, Android Inc., Linux Ltd.) — each thinks they rent a whole floor. EL0 is employees at desks — apps and services. The modem (AMSS) is a separate building on the same campus — connected by a road (shared memory / IPC), not a floor in the high-rise.

Mnemonic: EL0 = apps, EL1 = OS kernel, EL2 = hypervisor, EL3 = secure monitor — higher number = more power.

Typical vCPU Layout

Programs vary, but this reference layout appears across many SA8155P/SA8295P integrations:

vCPU Range	Guest OS	Role	Scheduling
0–1	QNX (host)	Hypervisor host, gateway, cluster, audio routing, safety services	Pinned, FIFO / sporadic
2–5	AAOS (guest)	Infotainment, navigation, voice UI, Android apps	Semi-pinned or floating, round-robin
6–7	Linux (guest, optional)	ADAS visualization, data logging, CV pre-processing	Program-dependent

On SA8295P with more physical cores, counts scale up, but the pattern holds: QNX owns real-time, AAOS owns HMI richness, Linux owns optional heavy compute.

QNX typically gets vCPU 0–1, AAOS gets the middle bulk (2–5), Linux is the optional last guest (6–7).

Common Gotcha

Beginner thinks vCPU numbers match Linux cpu IDs inside Android. Reality: Android sees cpu0–cpu3 within its VM, mapped to physical vCPU 2–5. A perf trace showing “CPU 0 at 100%” is guest CPU 0, not SoC core 0. Always ask: guest view or host view?

QNX Host vs AAOS Guest: Division of Labor

Responsibility	QNX (Host)	AAOS (Guest)
Real-time I/O	CAN/Ethernet gateway, low-latency audio	Consumes via VHAL / IPC
Display	Cluster, HUD (often), QNX Screen compositor	Center stack, passenger display
Safety proximity	Closer to ASIL-oriented services	Android framework: not ASIL-D certified alone
Boot order	Starts first, brings up hypervisor services	Starts after QNX IPC endpoints ready
Your debug tools	QNX Momentics, serial, slog2info	adb, logcat, systrace

QNX is host not because it’s “more important” in marketing terms, but because it owns the hypervisor integration and typically mediates hardware for guests.

Optional Linux Guest

Some programs add a third VM for:

• ADAS visualization: rendering fused sensor data
• Data logging / DVR: high-throughput storage without impacting AAOS jank
• Computer vision pre-processing: before sending results to QNX or AAOS

Linux guest is optional. Many SA8155P programs run QNX + AAOS only. SA8295P premium programs more often justify a third VM due to core count and display workload.

Think About It

AMSS doesn’t show up in the hypervisor’s VM list. Why not?

Reveal Answer

AMSS/MPSS runs on a separate modem/baseband processor with its own PBL→XBL→MPSS boot chain and QuRT RTOS — not as a Kryo vCPU guest under QHEE. The hypervisor only schedules apps-processor VMs (QNX, AAOS, optional Linux); modem firmware is flashed to modem partitions and debugged via QPST/QXDM, not adb. AP↔modem traffic uses SMD/GLink/QRTR cross-processor IPC, which never appears in a hypervisor VM list.

AMSS: Separate Processor, NOT a VM

This distinction saves careers:

	AAOS / QNX / Linux VM	AMSS (Modem)
Runs on	Kryo cores via hypervisor	Dedicated modem / baseband processor
OS	QNX, Linux (Android)	Modem RTOS (QuRT-based)
Boot chain	QHEE → ABL → guest kernel	Separate PBL → XBL → MPSS path
Flash partition	boot, vendor, qnx_ifs	modem, modemst, fsg etc.
Crash signature	Kernel panic, Android reboot	Modem SSR (Subsystem Restart)
Your tools	QFIL guest partitions, adb	QPST/QXDM, AMSS build drops

AMSS runs on separate modem silicon, not as a VM.

AMSS shares the SoC package and some memory bus with the apps processor, but it is not scheduled by QHEE as a guest OS. Inter-processor communication uses SMD (Shared Memory Device), GLink, or QRTR, not VirtIO.

Why QNX Is Host, Not AAOS

OEMs choose QNX as host because of deterministic scheduling, safety certification history, and direct hardware mediation for gateway and cluster. AAOS as guest leverages app ecosystem without certifying the entire Linux kernel to ASIL-D. The arrangement is integration policy, not a Qualcomm hardware requirement, but it’s the de facto standard on SA8155P/SA8295P programs.

Full SoC Layout Diagram

flowchart TB
    subgraph AP["Applications Processor (Kryo Cluster)"]
        subgraph HV["QHEE Hypervisor — EL2"]
            subgraph VM0["VM0 — QNX Host<br/>vCPU 0–1 · EL1/EL0"]
                QNX["Gateway · Screen · Audio · Safety"]
            end
            subgraph VM1["VM1 — AAOS Guest<br/>vCPU 2–5 · EL1/EL0"]
                AAOS["Android · VHAL · CarService · Apps"]
            end
            subgraph VM2["VM2 — Linux Guest (Optional)<br/>vCPU 6–7 · EL1/EL0"]
                LIN["ADAS Viz · Logging · CV"]
            end
        end
        TZ["TrustZone — EL3"]
        GPU["Adreno GPU"]
        DSP["Hexagon DSP"]
        ISP["Spectra ISP"]
    end

    subgraph MP["Modem Processor (Separate)"]
        AMSS["AMSS / MPSS<br/>Modem RTOS · LTE/5G"]
    end

    subgraph IO["Shared I/O"]
        CAN["CAN / CAN FD"]
        ETH["Automotive Ethernet"]
        DISP["Display Outputs"]
        UFS["UFS Storage"]
    end

    TZ -.->|"Secure services"| HV
    VM0 --> CAN
    VM0 --> ETH
    VM0 --> DISP
    VM1 --> GPU
    VM0 --> DSP
    VM0 --> ISP
    VM0 <-->|"SMD / GLink / QRTR"| AMSS
    VM1 <-->|"VHAL via vsock/gRPC"| VM0
    HV --> UFS
    AMSS -->|"Cellular RF"| ANT["Antenna"]

Where You'll See This

When triaging a bug, first identify which OS domain owns the symptom:

Symptom	Likely Domain
Cluster frozen, AAOS fine	QNX VM: display/audio path, vCPU 0–1
Android UI jank, cluster OK	AAOS VM: vCPU 2–5, GPU contention
Telematics dead, IVI fine	AMSS: modem processor, not adb logcat
Both VMs reboot together	QHEE / hypervisor or power: check serial from boot
Secure key / DRM failure	TrustZone (EL3): tz, keymaster, devcfg

Your serial console log during boot should show: PBL → XBL → QHEE → QNX VM start → AAOS VM start → modem bring-up. Missing “QNX VM start” but modem OK? Don’t flash vendor.img. Fix QNX IFS and VM config.

Connect the Dots

Page 5.2 traced boot to user space. Page 5.3 explained VM creation and vCPU scheduling. This page is the reference architecture you’ll sketch on whiteboards. Page 5.5 shows how VM0 and VM1 communicate (VHAL path). Module 6 dives into VHAL and CarService on the AAOS side. Module 7 is entirely AMSS on the modem processor.

Quick recap

1. EL3 (TZ) → EL2 (QHEE) → EL1 (kernels) → EL0 (apps): know the privilege stack.
2. Typical layout: QNX vCPU 0–1, AAOS vCPU 2–5, Linux vCPU 6–7 (optional).
3. AMSS runs on a separate modem processor, not a hypervisor guest.
4. Guest cpu0 inside Android ≠ SoC core 0. Always clarify guest vs physical view.

Check Your Understanding

1. Where does AMSS execute on a Qualcomm cockpit SoC?

Recall

A. As a loadable Linux kernel module inside the AAOS guest VM at EL1B. On a separate modem/baseband processor with its own boot chain and RTOSC. Inside TrustZone at EL3 running as a signed secure applet alongside keysD. As a guest VM on vCPU 6–7 managed by the QHEE hypervisor layer

2. In the typical cockpit vCPU layout, which pairing is correct?

Recall

A. QNX host on vCPU 0–1, AAOS guest on vCPU 2–5B. AAOS host on vCPU 0–1, QNX guest on vCPU 2–5C. AMSS on vCPU 0–1, QNX on vCPU 2–5D. TrustZone on vCPU 2–5, QHEE on vCPU 0–1

3. Android systrace shows 'CPU 0' at 100%. What should you clarify first?

Applied

A. Whether PBL ROM code has been replaced with a custom first-stage loaderB. Whether the AMSS modem firmware version is outdated on the baseband DSPC. Whether this is guest CPU 0 inside the AAOS VM or physical SoC core 0D. Whether the CAN bus link runs at 1 Mbps classic or CAN FD data phase

4. Which ARM exception level runs the TrustZone secure monitor?

Recall

A. EL3 — secure monitor (keys, crypto, SMC dispatch)B. EL1 — guest OS kernelsC. EL2 — QHEE hypervisorD. EL0 — user applications

5. Telematics is dead but IVI (cluster + center stack) works fine. Where should you focus debugging first?

Applied

A. PBL ROM replacement — corrupted first-stage bootloader in SPI NOR flashB. AMSS on the modem processor — separate boot chain, not adb logcat visibleC. AAOS VHAL timeout — vehicle speed property handler stalled in the HAL layerD. QHEE hypervisor VM scheduler — a vCPU starvation or priority inversion bug

6. In a zonal E/E architecture, the cockpit domain controller runs Adaptive AUTOSAR services on QNX while AAOS handles HMI. How does this map to the multi-OS layout on SA8295P?

Synthesis

Connects to: Module 4 — AUTOSAR

A. Adaptive AUTOSAR replaces QHEE at EL2 to manage VM scheduling directlyB. AMSS hosts Adaptive AUTOSAR services because it already runs a modem RTOSC. Classic runs on QNX vCPU 0–1; AAOS consumes via VHAL IPC; MCUs keep ClassicD. All AUTOSAR stacks run inside the AAOS guest VM as standard Android apps

Further Reading

• QNX Advanced Virtualization Frameworks Architecture — QNX reference architecture for cockpit domain controllers with QNX host and Android guest, including resource sharing and display assignment patterns.
• Android Automotive OS Overview — Google’s official AAOS platform documentation covering hardware requirements, feature declarations, and OEM integration for infotainment guest VMs.
• Snapdragon Cockpit Platform — Qualcomm’s multi-OS cockpit platform overview showing how QNX, AAOS, and Linux distributions coexist on a single automotive SoC.
• Qualcomm AI Runtime — Automotive Target Environments — Documents LA GVM (Android guest VM) and LV GVM (Linux guest VM) target environments on SA-series SoCs, mapping to the multi-OS layout described here.
• ARM Trusted Firmware-A — Exception Levels — Reference for the EL3 (TrustZone) → EL2 (hypervisor) → EL1 (kernel) → EL0 (apps) privilege stack that structures multi-OS isolation on ARM SoCs.
• QNX Hypervisor for Safety — Product documentation for safety-certified VM consolidation that supports mixed-criticality layouts with QNX host and AAOS guest on shared Kryo cores.
• Android Automotive OS for Software-Defined Vehicles — Google’s SDV platform vision including topology-agnostic communication and multi-compute consolidation relevant to next-generation cockpit layouts.