TPT Construct — The QEMU Successor

A strictly memory-safe, modular hypervisor and hardware emulator in Rust, where device emulation is isolated and crash-proof.

Copyright (c) TPT Solutions. Licensed under either of:

• MIT license (LICENSE-MIT)
• Apache License, Version 2.0 (LICENSE-APACHE)

at your option.

Why

QEMU emulates entire CPUs and hardware devices in C. A single memory bug allows a VM escape — a malicious guest breaks out of its sandbox and executes code on the host. TPT Construct replaces that with a Rust codebase whose type system makes guest/host memory aliasing a compile-time impossibility, and whose device emulation is driven by an AI + Knowledge-Graph pipeline that ports QEMU's C devices into async Rust.

Architecture

                 ┌─────────────────────────────────────────────┐
                 │                hypervisor-core                │
                 │  Vm · Vcpu · GuestMemory (strict owner)   │
                 └───────────────────┬─────────────────────────┘
                                     │  trait boundary
                 ┌───────────────────┴─────────────────────────┐
                 │            hv-backend-abstraction             │
                 │   VmBackend · VcpuBackend · MemoryBackend   │
                 └───────┬───────────────────────────┬─────────┘
                         │                           │
                 ┌───────▼────────┐        (future) ┌──────────────┐
                 │ hv-backend-kvm │                │ Hyper-V / HVF │
                 │  (Linux KVM)  │                └──────────────┘
                 └───────┬────────┘
                         │
   ┌──────────────┬──────▼───────┬──────────────┬───────────────┐
   │  device-io  │  devices/nvme │ sys-util-ext │ kg-pipeline │ test-harness │
   │ async event  │ virtual NVMe  │  mmap/eventfd│ C→KG→Rust   │ QEMU oracle  │
   │   loop (mio)│  controller   │   wrappers   │  pipeline    │  diff + report│
   └──────────────┴───────────────┴──────────────┴──────────────┴───────────────┘

• hypervisor-core — backend-agnostic VM lifecycle, vCPU management, and a strict-ownership guest-memory model.
• hv-backend-abstraction — the trait layer (VmBackend, VcpuBackend, MemoryBackend) that any accelerator implements.
• hv-backend-kvm — the Linux KVM backend (kvm-ioctls). Windows (Hyper-V/WHP) and macOS (Hypervisor.framework) backends are stubbed at the trait boundary and tracked for later phases.
• device-io — the mio-based async device event loop and the AsyncDevice trait. Devices yield instead of busy-polling, cutting host CPU overhead vs. QEMU.
• devices/nvme — the first device emulator: a virtual NVMe controller (register space, admin/I-O queues, async DMA, MSI-X).
• sys-util-ext — safe wrappers around vmm-sys-util (mmap, eventfd).
• kg-pipeline — ingest QEMU C → extract a Knowledge Graph of the hardware state machine → generate async Rust → verify at runtime.
• test-harness — the cycle-accurate harness that diffs TPT Construct against a reference QEMU oracle and emits pass/fail + divergence reports.

See docs/memory-safety.md for the VM-escape argument, and docs/msrv.md for the MSRV policy.

Building

Requires Rust 1.77.0 or later (see rust-toolchain.toml).

# Check the whole workspace
cargo check --workspace

# Build
cargo build --workspace

# Test
cargo test --workspace

# Run the clippy lints used in CI
cargo clippy --workspace --all-targets -- -D warnings

Note: the KVM backend only functions on Linux with /dev/kvm available. On other platforms the crate still compiles (so the workspace builds cross-platform) but KvmBackend::new returns BackendError::Unavailable.

Status

Phase 0 (project foundation) and Phases 1-8 are substantially complete: the workspace, all crates, the backend trait layer, the KVM backend, the async device framework, the NVMe controller, the KG pipeline (now wired end-to-end through an NVMe C-source integration test), and the test-harness comparison engine. Guest architecture support covers both x86_64 (real-mode to long-mode boot, CPUID, firmware/boot-ROM generator) and AArch64 (PSCI boot protocol, GICv2/v3, EL1 boot). The launcher performs arch-aware boot orchestration, graceful shutdown/reset, and VM snapshot (pause/resume). Memory safety is validated under Miri in CI. Remaining work is tracked in todo.md: the live QEMU oracle and cycle-accurate harness validation, additional devices (virtio, legacy), functional Windows/macOS backends, RISC-V, multi-VM orchestration, and the benchmarking/docs site.