Hardware Readiness Gate

Hardware Readiness Gate

Purpose

This page defines the gate between the QEMU on macOS correctness track and the first Intel Desktop hardware bring-up.

OSAI must not treat QEMU results as hardware performance evidence. QEMU validates boot contracts, resource ownership, userspace control flow, telemetry shape, security policy behavior, persistence metadata, and preview packaging.

QEMU Gate

The milestone 33 local QEMU hardware-readiness gate is:

• make qemu-readiness-gate

That command runs the full local QEMU matrix and then validates the generated artifacts. It writes:

• build/qemu-benchmark-report.json
• build/qemu-preview-manifest.json
• build/qemu-cpu-matrix-report.json
• build/qemu-readiness-report.json

The benchmark schema is osai.qemu.correctness_benchmark.v1. The preview schema is osai.qemu.preview.v1. The CPU matrix schema is osai.qemu.cpu_matrix.v1. The readiness schema is osai.qemu.hardware_readiness_gate.v1. The frozen QEMU release-candidate contract schema is osai.qemu.release_candidate_contract.v1.

These reports are correctness artifacts only and explicitly do not authorize Linux, BSD, or hardware performance claims.

Frozen QEMU Contracts

The following contracts must remain green before Intel Desktop work starts:

• AArch64 UEFI loader boots the kernel.
• UEFI memory map is parsed into PMM/VMM state.
• Controlled page, read-only write, and NX execute faults are reported through the exception path.
• Real EL0 /init ELF loads from the VirtIO-backed read-only filesystem.
• Syscalls enforce capability checks and user pointer validation.
• Syscall ABI, telemetry schema, read-only initramfs format, persistence record format, and service descriptor format are frozen in contracts/qemu-rc-v1.json.
• Security policy enforces capabilities, filesystem boundaries, workspace and sandbox ownership, rollback authorization, credential rejection, and signed-update format validation.
• Persistence metadata snapshots and rolls back boot, service, workspace, and sandbox records.
• VirtIO block and VirtIO net self-tests pass.
• AI Cell lifecycle, core leases, shared model arena, private KV/cache, source index, Git workspace, sandbox, CPU-AI runtime, and low-latency network smoke paths emit telemetry.
• Hot AI core telemetry reports zero migration and zero involuntary context switches under the QEMU gate.
• CPU matrix tiers validate the default ARM64 host/HVF smoke path, ARM64 TCG boot probes, and Intel/AMD x86_64 command profiles.

Out of Scope Before Intel

The QEMU release-candidate gate intentionally does not claim:

• performance wins against Linux or BSD;
• x86_64 OSAI kernel boot;
• Intel APIC, HPET, TSC-deadline, PCIe, NVMe, and NIC hardware drivers;
• production update signing and key management;
• a production mutable filesystem;
• real model file formats or production CPU-AI model runtimes;
• network throughput benchmarking;
• multi-user security policy and remote administration hardening.

Intel Desktop Entry Criteria

Intel Desktop bring-up can start when:

• make qemu-readiness-gate passes locally.
• The QEMU preview manifest exists.
• The QEMU benchmark report exists.
• The QEMU CPU matrix report exists.
• The QEMU readiness report exists and has status pass.
• The QEMU RC contract exists and remains frozen.
• No QEMU benchmark result is described as a hardware speedup.
• The platform and benchmark documentation reflect the current gate.

First Intel Desktop Deliverables

• UEFI x86_64 boot path.
• Serial console and early exception reporting.
• PMM/VMM initialization from x86_64 firmware memory maps.
• APIC and timer discovery.
• PCI discovery for NVMe and NIC planning.
• P-core/E-core placement policy metadata.
• Initial tuned Linux/BSD baseline plan for later measured comparisons.

Related Pages

• QEMU on macOS
• Intel Desktop Port
• Testing and Benchmarking
• Performance Targets