Claim C2 Ring Measurement Evidence — 2026-08-02
This bundle supports the
Claim C2 Ring Measurement
record. Five foreground make test-measure runs used clean source commit
4c68f10139eefd29ac0db38dc721409f2b6067f1 and pinned QEMU to host logical
CPU 0:
CAPOS_MEASURE_QEMU_TASKSET_CPUS=0 \
CAPOS_MEASURE_ARTIFACT_DIR=target/paper-c2-measure-20260802/run-N \
make test-measure
The run interval was 2026-08-02 15:01:21–15:03:57 UTC. QEMU 8.2.2 used
KVM, one qemu64 guest vCPU, and 256 MiB guest RAM. The KVM host exposed
eight logical CPUs, four cores, two threads per core, and an Intel Xeon
2.80 GHz CPU. Pinning constrained QEMU’s affinity but did not isolate CPU 0
from other host work. host.txt retains the host
envelope.
Each make invocation rebuilt capos-measure.iso; consequently, the five
invocation records have distinct ISO SHA-256 values even though all name the
same clean source commit. Each record also retains the resolved QEMU command
and QEMU version.
| Run | Invocation | Kernel serial | Terminal |
|---|---|---|---|
| 1 | run-1 | run-1 | run-1 |
| 2 | run-2 | run-2 | run-2 |
| 3 | run-3 | run-3 | run-3 |
| 4 | run-4 | run-4 | run-4 |
| 5 | run-5 | run-5 | run-5 |
Extracted observations
| Run | Warmed NOP cycles | NullCap empty cycles | NullCap schema cycles | Schema overhead cycles | CALL-to-receiver cycles | Direct ready-to-select cycles |
|---|---|---|---|---|---|---|
| 1 | 33,894 | 37,759 | 5,111,471 | 6,081 | 7,969,332 | 402,336 |
| 2 | 32,436 | 37,741 | 43,922 | 4,916 | 7,902,385 | 400,517 |
| 3 | 34,339 | 37,622 | 44,665 | 4,141 | 7,938,635 | 406,615 |
| 4 | 32,755 | 36,553 | 44,440 | 4,015 | 7,882,146 | 393,480 |
| 5 | 32,696 | 37,047 | 45,413 | 4,173 | 7,929,650 | 396,793 |
| Median | 32,755 | 37,622 | 44,665 | 4,173 | 7,929,650 | 400,517 |
| Range | 32,436–34,339 | 36,553–37,759 | 43,922–5,111,471 | 4,015–6,081 | 7,882,146–7,969,332 | 393,480–406,615 |
The user-side NullCap columns come from [ring-nop] measure avg cycles and
include ring publication, cap_enter, dispatch, and completion consumption.
The schema-overhead column comes from
measure: schema_dispatch_overhead; it subtracts the kernel’s aligned
NullCap empty-method segment average from its schema-parsing method average.
Each path has one timing-guard lifecycle. The schema guard records its single
interval into both null_cap_schema and capnp_decode_encode, rather than
nesting a second timer inside the schema interval. Both NullCap segment
counters observed 80 calls in every run. The direct ready-to-selection
intervals ranged from 378,888 to 548,506 cycles across all 355 observed direct
selections.
The capability-slot record was identical in every run:
measure: cap_slot_memory slot_bytes=80 max_slots=256 max_slot_storage_bytes=20480. The 80-byte figure is inline CapSlot vector
storage on this x86_64 build. It excludes allocator metadata and separately
allocated or shared capability objects and epoch cells, so it is not total
per-capability heap ownership.
The global dispatch segments provide diagnostic attribution rather than isolated workload costs:
| Segment average | Median cycles | Five-run range |
|---|---|---|
ring_processing | 5,318,289 | 5,292,060–5,987,924 |
sqe_validation | 19,508 | 19,127–19,740 |
cap_lookup | 584,498 | 584,168–763,821 |
capnp_decode_encode | 7,029 | 6,565–7,129 |
method_body | 8,414,672 | 8,359,230–9,250,237 |
cqe_post | 551 | 509–657 |
waiter_wake_check | 11,745 | 11,307–12,519 |
These boot-global segments combine all workloads in the measure manifest and may be nested; they must not be summed into an end-to-end latency.
Evidence boundary
The bundle closes the schema-dispatch and inline capability-slot-storage measurements. It does not close three distinct measurements:
- The NOP line is a warmed, eight-SQE batched cycle average. It does not
report a cold-ring sample, so it cannot supply a warm-versus-cold
cap_entercomparison. measure: ring dispatches=... sqes=...reports boot-global counts without a calibrated elapsed interval. It is not SQE throughput in operations per second.- The CALL-to-receiver workload mixes direct and ordinary scheduling, while
direct_ipc_ready_to_selecttimes only observed direct selections. Neither line measures a matched ordinary-scheduler baseline, so they do not provide a scheduler-versus-direct-switch latency comparison.
These are nested-QEMU/KVM cycle observations from one 156-second collection window. Host affinity is not isolation, guest TSC behavior is virtualized, and the measure image retains other debug instrumentation. The ranges characterize only these five runs; they are not reproducibility bounds, hardware results, or production-performance claims.
The serial logs retain QEMU’s CRLF output. SHA-256 digests below are for their LF-normalized contents:
c3c5742efdb006c177497fd5c7f9fbc3baa4967ddac4e6705239af74d075f2d2 run-1-kernel.txt
2503a4373576118f6dff48b168b5027e937b752d42e89bf1bdb128b3c47a240e run-2-kernel.txt
693988bb51a911aaffa47012f8b9161081b60e9c59af3bbba3981dd3360516d1 run-3-kernel.txt
29130c2f78c5d726655f74c020bcdd4651d15747274886a50e3fdbe2ac2db514 run-4-kernel.txt
a84e9b3d8840c7793b5d08e76e981ebf16c27cdd7446d0f86fc30e619b83b1c9 run-5-kernel.txt
The terminal files contain only QEMU’s unsupported-SVM-feature warning.
tools/qemu-measure-smoke.sh verified every run’s required output and clean
proof termination.