Multi-OS Layout on the SoC

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.

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.

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

vCPU numbers are not Linux cpu IDs inside Android. 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.

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?

A. As a guest VM on vCPU 6–7 under QHEEB. On a separate modem/baseband processor with its own boot chain and RTOSC. Inside TrustZone at EL3 as a secure appletD. As a Linux kernel module inside AAOS

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

A. AAOS host on vCPU 0–1, QNX guest on vCPU 2–5B. QNX host on vCPU 0–1, AAOS 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?

A. Whether this is guest CPU 0 inside the AAOS VM or physical SoC core 0B. Whether AMSS modem firmware is outdatedC. Whether the CAN bus is at 1 Mbps or CAN FDD. Whether PBL ROM has been replaced