Hypervisor & Virtual Machines
A cockpit SoC runs multiple operating systems simultaneously: QNX for real-time and safety, AAOS for infotainment, sometimes Linux for ADAS, all on one Kryo CPU cluster. A Type-1 hypervisor runs directly on hardware (no host OS underneath) and creates Virtual Machines (VMs) with isolated memory, assigned vCPUs, and controlled device access. On Qualcomm silicon, QHEE is the EL2 hypervisor firmware; QNX Hypervisor (or equivalent host stack) manages VM lifecycle on top. You configure vCPU pinning, scheduling policies, and device passthrough in VM configs, then flash vCPU images that map to specific virtual cores.
You’ve seen vcpu0, vcpu1 in flash manifests and VM config XML. This page explains what a vCPU actually is and who schedules it.
Type-1 vs Type-2 Hypervisors
Section titled “Type-1 vs Type-2 Hypervisors”| Type-1 (Bare-Metal) | Type-2 (Hosted) | |
|---|---|---|
| Runs on | Hardware directly | On top of a host OS |
| Examples | QHEE, QNX Hypervisor, Xen automotive | VirtualBox, VMware Workstation |
| Latency | Lower: no host OS layer | Higher: host OS competes for resources |
| Automotive use | Standard for cockpit | Lab/dev only |
Type-1 means one layer between silicon and guest OS. Type-2 adds a host OS in between.
Cockpit platforms use Type-1 because ASIL-oriented workloads need predictable scheduling and hardware isolation, not a desktop VM running inside Windows.
QHEE vs QNX Hypervisor: Who Does What?
Section titled “QHEE vs QNX Hypervisor: Who Does What?”Two names, one stack. Don’t conflate them:
| Layer | Name | Role |
|---|---|---|
| EL2 firmware | QHEE (Qualcomm Hypervisor Execution Environment) | ARM virtualization extensions, stage-2 MMU, trap handling, low-level VM entry/exit |
| Host OS + tooling | QNX Hypervisor (or QNX as host) | VM creation API, device model, scheduling policy, guest lifecycle, inter-VM IPC setup |
QHEE is Qualcomm’s silicon-specific hypervisor binary, loaded in the boot chain (Page 5.2). QNX Hypervisor is the management layer your integration team configures: VM XML, resource tables, startup scripts.
The apartment building manager (QHEE + QNX Hypervisor) owns the building (physical CPU, memory, I/O). Each apartment (VM) gets:
- Assigned rooms (memory regions — no peeking into neighbors’ closets)
- Named residents (vCPUs) with keys to specific facilities (device passthrough)
- House rules (scheduling policy — FIFO for real-time tenant, round-robin for infotainment)
The manager doesn’t cook dinner in your apartment — it enforces walls and schedules elevator access. When AAOS hogs the GPU, that’s a resource negotiation the manager mediates, not QHEE “running Android.”
How VMs Are Created
Section titled “How VMs Are Created”VM creation is configuration-driven, defined at integration time and applied at boot:
1. vCPU Allocation
Section titled “1. vCPU Allocation”Physical Kryo cores are time-sliced or pinned to virtual CPUs:
| Concept | Meaning |
|---|---|
| vCPU | Virtual CPU seen by guest OS: appears as cpu0, cpu1 inside the VM |
| pCPU | Physical Kryo core on the die |
| Pinning | vCPU always runs on a specific pCPU, critical for determinism |
| Floating | vCPU migrates among available pCPUs: better utilization, less deterministic |
Typical cockpit layout (detailed on Page 5.4):
- QNX host: vCPU 0–1 (pinned, FIFO scheduling)
- AAOS guest: vCPU 2–5 (may float or semi-pin)
- Linux guest: vCPU 6–7 (optional, workload-dependent)
Pin for predictable real-time work. Float for flexible infotainment.
2. Memory Partitioning
Section titled “2. Memory Partitioning”The hypervisor assigns physical memory regions to each VM via stage-2 page tables:
- Each VM sees a contiguous or scattered RAM map, only its regions
- Shared memory windows (e.g., RTISM) are explicitly carved out, never accidental overlap
- Ballooning and overcommit are rare in automotive. Memory is statically partitioned at boot
| VM | Typical RAM Budget (Example) |
|---|---|
| QNX host | 2–4 GB |
| AAOS guest | 4–8 GB |
| Linux guest | 1–2 GB |
Exact numbers are program-specific. Read your VM config, not this table.
3. Device Passthrough vs Emulation
Section titled “3. Device Passthrough vs Emulation”| Mode | Behavior | Use Case |
|---|---|---|
| Passthrough | VM owns physical device directly (with IOMMU isolation) | Display controller, GPU, critical CAN controller |
| Emulated (VirtIO) | Hypervisor presents virtual device | Network, block storage, IPC channels |
| Split / mediated | Hypervisor multiplexes hardware (e.g., GPU slices) | Shared Adreno for multiple displays |
Gotcha territory: Passthrough gives performance and determinism but exclusivity. Two VMs can’t passthrough the same physical block without mediation.
“Give Android direct access to the GPU for performance”: passthrough means QNX loses direct access to that block unless the hypervisor mediates. Display ownership fights between QNX Screen and Android SurfaceFlinger are hypervisor config issues, not app bugs.
vCPU Scheduling Policies
Section titled “vCPU Scheduling Policies”The hypervisor scheduler decides which vCPU runs on which pCPU when:
| Policy | Behavior | Typical Assignment |
|---|---|---|
| FIFO (First-In-First-Out) | Run until block or preemption by higher priority | QNX safety services, cluster rendering |
| Round-robin | Time-sliced among equal-priority vCPUs | AAOS background tasks |
| Sporadic / budget | CPU budget per period: ASIL-friendly throttling | Mixed-criticality programs |
| Pinned + FIFO | Fixed core + no migration + priority inheritance | Instrument cluster VM |
Pinned vs floating summary:
Pinned: vCPU2 ──always──▶ pCPU2 (deterministic, may idle)Floating: vCPU4 ──may move──▶ pCPU2, pCPU3, pCPU4 (efficient, variable latency)FIFO suits real-time work. Round-robin rotates runtime for fairness.
ARM Virtualization Extensions
QHEE relies on ARM Virtualization Extensions: EL2 hypervisor mode, stage-2 translation (guest physical → real physical), and virtual interrupt controller (GICv3/v4). Guest OSes run at EL1 believing they own the machine, trapping to EL2 on privileged accesses. You won’t configure EL2 directly, but GIC and timer passthrough in VM XML affect interrupt latency for QNX ISR handlers.
When you flash “vCPU images”, you’re updating the OS on specific virtual cores.
A flash manifest might list:
qnx_ifs→ boots on vCPU 0–1 (QNX host VM)boot.img/vendor.img→ boots on vCPU 2–5 (AAOS guest)linux_boot→ boots on vCPU 6–7 (optional ADAS VM)
Flashing the wrong image to the wrong VM slot doesn’t change vCPU assignment (that’s in VM config). A mismatched kernel vs VM config (wrong device tree, wrong RAM size) causes boot loops that look like “hypervisor broken.”
Daily checks:
- VM config XML — vCPU count, pinning, memory map
- Flash XML — which partition targets which guest
- Serial log at QHEE init — “VM0 start OK, VM1 start FAIL” pinpoints guest config errors
Page 5.2 showed QHEE loading in the boot chain. This page explains what QHEE does once running. Page 5.4 maps which OS occupies which vCPUs. Page 5.5 covers how VMs talk without breaking isolation. Module 6 connects the AAOS guest to VHAL over inter-VM IPC.
In brief
Section titled “In brief”- Cockpit uses a Type-1 hypervisor: QHEE at EL2, QNX Hypervisor for management.
- VMs get vCPUs, memory regions, and device access, configured statically at integration.
- Pinned + FIFO for QNX real-time; floating + round-robin for AAOS throughput.
- vCPU images in your flash workflow map to guest OS instances, not physical core firmware.
Check Your Understanding
1. In the apartment building mental model, what does the building manager (hypervisor) primarily enforce?
2. When should a QNX safety-critical VM use pinned vCPUs with FIFO scheduling instead of floating vCPUs with round-robin?
3. What is the relationship between QHEE and QNX Hypervisor?