Hypervisor & Virtual Machines

Advanced11 min read

Assumes: 1.3 Why Isolation Matters, 5.1 Platform Overview

TL;DR

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. Virtual machines that share silicon but would never share a secret.

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?

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.

Mental Model

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.”

Mnemonic: Type-1 hypervisor = the building itself, not a tenant. It IS the floor plan.

Think About It

QNX and Android are both running on the same SoC. Android’s memory allocation grows unbounded. What prevents it from starving QNX?

Reveal Answer

Static memory partitioning via QHEE stage-2 page tables — each VM gets fixed physical RAM at boot, and AAOS cannot map or balloon into QNX regions. vCPU pinning (QNX on vCPU 0–1, AAOS on 2–5) plus FIFO/sporadic CPU budgets guarantee QNX cluster and gateway cycles even when Android heap grows. On bench, read VM config XML for memory carveouts and scheduler policy; if QNX starves, the bug is almost always config — not Android “using too much RAM” inside its own cage.

How VMs Are Created

VM creation is configuration-driven, defined at integration time and applied at boot:

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

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

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.

Common Gotcha

Beginner thinks the hypervisor is an OS you can shell into. Reality: it’s a thin partitioning layer at EL2 — it schedules vCPUs, maps memory, and mediates device access, but doesn’t run applications or provide a user shell. QNX and AAOS are the actual operating systems; QHEE is the referee between them.

If you give Android direct GPU passthrough for performance, 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

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.

Where You'll See This

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:

1. VM config XML — vCPU count, pinning, memory map
2. Flash XML — which partition targets which guest
3. Serial log at QHEE init — “VM0 start OK, VM1 start FAIL” pinpoints guest config errors

Connect the Dots

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

1. Cockpit uses a Type-1 hypervisor: QHEE at EL2, QNX Hypervisor for management.
2. VMs get vCPUs, memory regions, and device access, configured statically at integration.
3. Pinned + FIFO for QNX real-time; floating + round-robin for AAOS throughput.
4. 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?

Recall

A. Memory isolation, vCPU scheduling, and controlled device access between VMsB. Cooking meals inside each tenant's apartmentC. Running AMSS modem firmware as a managed guest VM on the Kryo clusterD. Compiling and optimizing Android application packages for AAOS deployment

2. When should a QNX safety-critical VM use pinned vCPUs with FIFO scheduling instead of floating vCPUs with round-robin?

Applied

A. When flashing AMSS modem firmware from the applications processor sideB. When deterministic low-jitter execution on known physical cores is neededC. When minimizing cloud OTA bandwidth usage for infotainment updatesD. When the VM needs maximum total throughput regardless of latency spikes

3. What is the relationship between QHEE and QNX Hypervisor?

Recall

A. They are the same binary with different namesB. QHEE is a Type-2 hypervisor running inside AAOSC. QNX Hypervisor replaces QHEE entirely on SA8295PD. QHEE is EL2 hypervisor firmware; QNX Hypervisor is the host-side VM manager

4. Why is a Type-1 hypervisor standard for automotive cockpit platforms instead of Type-2 (hosted)?

Applied

A. Type-2 hypervisors have a hard limit of creating only one guest virtual machineB. Type-2 hypervisors are prohibited under AEC-Q100 qualification standardsC. Type-1 hypervisors can only operate on 14 nm or smaller silicon process nodesD. Type-1 runs on bare metal with lower latency — no host OS competing for cores

5. Two VMs both request exclusive GPU passthrough for maximum frame rate. What is the hypervisor-level consequence?

Applied

A. GPU passthrough mode disables the QHEE hypervisor layer entirely on the SoCB. The hypervisor automatically converts any passthrough request to VirtIO netC. Passthrough grants exclusivity — only one VM owns the GPU unless mediatedD. Both VMs can passthrough the same Adreno block simultaneously without mediation

6. An OEM pursues ASIL decomposition with QNX cluster on pinned vCPU 0–1 and AAOS on floating vCPU 2–5. Which ISO 26262 concern does hypervisor memory partitioning directly address?

Synthesis

Connects to: Module 9 — Safety & Diagnostics

A. Eliminating the need for any ISO 26262 safety case documentation entirelyB. FFI — stage-2 page tables prevent AAOS from accessing QNX safety memoryC. Replacing Classic AUTOSAR on all chassis MCU ECUs with Adaptive servicesD. Disabling TrustZone at EL3 to achieve faster cold-boot startup times

Further Reading

• QNX Hypervisor for Safety — Official QNX Type-1 hypervisor product page covering VM isolation, deterministic scheduling, device passthrough, and safety certification (ISO 26262 ASIL D).
• Qualcomm Gunyah Hypervisor (GitHub) — Open-source Type-1 hypervisor from Qualcomm supporting protected VMs, relevant to understanding QHEE’s design lineage and ARM virtualization on Snapdragon platforms.
• Qualcomm Developer Blog — Gunyah Hypervisor — Engineering overview of Gunyah’s architecture, use cases, and integration with Android Virtualization Framework on Qualcomm chipsets.
• ARM Virtualization Host Extensions (VHE) — ARM architecture documentation for EL2 hypervisor support, explaining the hardware virtualization primitives that QHEE and QNX Hypervisor rely on for vCPU scheduling.
• QNX Advanced Virtualization Frameworks Architecture — QNX documentation for multi-OS resource sharing (graphics, audio, input) between hypervisor host and guest VMs on cockpit domain controllers.
• ARM Architecture — Exception Levels and Virtualization — Detailed ARM virtualization support documentation covering stage-2 translation, virtual interrupt controllers, and vCPU context switching at EL2.