Off the emulator, onto real virtualization.

Every number on this page used to come from QEMU under TCG — software emulation, where each privileged instruction is interpreted. Arkane now boots on KVM on AMD hardware: the same kernel, but the CPU executes it. That is the first time the measurements mean anything about speed — and it is the first time Arkane and Linux were timed on the same machine, with the same counter, in the same run.

                  arkane   linux
syscall              224    1393  getpid
ipc round-trip     36850   40864  af_unix

→ syscall ~6× faster · ipc ~10% faster

The honest frame, stated before anyone asks for it: one host, dev-profile build, n=2 runs. That is a first datapoint, not a benchmark suite — no claim about other hardware, other workloads, or a release build follows from it, and the IPC figures are raw counter values from the same harness on both sides: the pair is the result, not the unit. What it does settle is the direction: the syscall path is genuinely short, and IPC is not the liability the emulator made it look like.

It also corrects us. Under TCG the IPC round-trip measured 3.5× slower than Linux, and that was the working assumption — the thing to go fix. On real virtualization the same path is 10% faster. The old figure was an emulation artefact: TCG's cost model, not Arkane's. It is named here rather than quietly dropped, because a measurement culture that only publishes the flattering revisions is not one.

The full serving path has a correction of its own. Its first KVM run put Arkane at 5.5–10.8× Linux's latency. Before optimising anything, we decomposed it: 80–89% of that latency was our own debug serial output, written on every request. With it switched off, Arkane serves at 0.98–1.34× Linux — parity on the public tree, 1.2–1.35× behind on the rest. Honest benchmarks find your own mistakes too.

                   R_p50   (<1 = arkane faster)
public-tree        0.977   parity
static-json        1.224
mcp-notes-search   1.285
mcp-echo           1.344

→ parity on public-tree · 1.2–1.35× behind elsewhere

Same frame as above: one host, dev profile. Load was paced at 50 req/s, and both sides held that rate (throughput ratio 1.0–1.15). Peak capacity has not been measured yet. The tail is still wider, with p99 at 1.2–1.9× Linux. The remaining gap is real, and it is the next thing to work on.

Three kernel bugs that only a real CPU could find.

The first KVM boot did not work. Three bugs had been sitting in the kernel — green through every gate — because TCG checks loosely where hardware checks strictly. Each one is a rule the real CPU enforces and the emulator waved through:

1  IDT gaps          — vectors missing from the interrupt
                       descriptor table. TCG tolerated it; KVM did not.
2  MSI-X swapgs      — GS handling on the MSI-X interrupt path.
                       Wrong under strict checking, harmless under TCG.
3  SS.RPL selector   — stack-segment selector privilege bits.
                       The emulator accepted them; the CPU rejected them.
→ all three fixed · KVM boot green · measurement run followed

This is the argument for the proof culture, made by counter-example. 47+ acceptance gates were green and three real bugs were still there — not because the gates were weak, but because they ran on an environment kinder than reality. What found the bugs was not a better test. It was a stricter machine.

TCG hid them. KVM found them. An after-work PC proved it. No lab, no cluster, no budget — one AMD desktop, and the bugs had nowhere left to hide.

802 requests. 0 errors. During the update.

The gate keeps a client firing requests at the inference replica group while arkctl cell rollout restarts it — three times in a row. The gateway routes round-robin to whichever replica is alive; the rollout is ready-gated so the group never drops to zero. Result across three rollouts under sustained fire: 802 requests, 0 failed responses.

$ arkctl cell rollout inference   # ×3, client firing throughout
ROLLOUT_START · step 1: alive_before=2 · ready · step 2: alive_before=2 · ready · DONE
requests: 802 · errors: 0 · min alive: 1 (floor N−1)

This is the availability claim made concrete: updating an app never takes it down. The serial-log markers (START / STEP / READY / DONE, never ABORT) are what the gate greps for — not a dashboard screenshot.

Power-on to converged cluster: 7.4 s.

Measured in QEMU under TCG, unattended — no request needed to poke the system awake. The interesting part is what the gate found first: the kernel was never slow, but one cell waited indefinitely for its first network request, so an untouched boot never converged at all. The fix gave it a time budget; the gate now enforces convergence without any external stimulus. Boot under 3 s is a named optimization target, not yet claimed.

[0.0s]  kernel entry · 4 cores
[2.1s]  cells spawned · signatures verified
[6.8s]  TLS keys generated · console up
[7.4s]  cluster converged · 0 drift · no poke

Prove what ran — offline.

Every security-relevant event — spawn, stop, crash, capability grant, contract refusal, every console write — becomes an immutable block in a Blake3 hash chain, where each block's content hash is the next block's back-link, mirrored to disk. Verification needs the drive, not the running system.

$ arkctl audit verify --store store.img --list
audit chain OK: 23 blocks, head seq=22 hash=6b01c4…

$ printf '\x01' | dd of=store.img seek=571432 …   # flip ONE byte, anywhere
$ arkctl audit verify --store store.img
audit verify FAILED: TAMPER: block seq=4 does not
hash to its stored id (content was modified)

The honest boundary, stated exactly: the chain proves tampering and gaps after its last verified anchor. An attacker who controls the kernel before the first anchor can rewrite the story up to that point — external anchoring is on the roadmap, and until then this sentence is the precise edge of the claim.

Nothing readable on the disk.

Every app-data body is encrypted before it is mirrored — XChaCha20-Poly1305 under a key that lives only in a net-free keystore cell, RAM-only. The gate is a command anyone can run: strings store.img after a full write round-trip finds no plaintext. Flip one ciphertext byte and the read fails loudly — an AEAD error, never silent garbage. And credentials are injected per call by the gateway: the app never holds them, so a fully compromised app cannot leak a secret it never had.

$ strings store.img | grep -c "secret note body"
0   # the data is on disk — as ciphertext

Honest edge: at rest means the disk. The in-RAM blob table holds plaintext while the machine runs — the same edge as "it runs in QEMU". Crash recovery is proven the same way: apply → hard reboot → the cluster is still there, without re-applying anything. That gate has run on every merge since v0.14.