Performance Research C01 TB Lookup and Chaining

Static-state TB lookup and block chaining

C01 — Implementation and validation notes

Field	Value
Evidence state	QEMU mechanism already exists; new eligibility/identity change requires proof
Inspected source	322986f4c5502b3fa887a9605ac8cd88e9b2c579
First experiment	One redundant key derivation or missed legal chain
Scope	Addendum dated September 15, 2026; not a current-main benchmark or implementation status

Unproven performance research · Performance research — common test protocol · Performance research — reproducible checks

Evidence and implementation reasoning

Established mechanism. QEMU specializes translation blocks using CPU state and links eligible blocks to avoid repeatedly returning to the dispatcher. Its documented design also requires exits when guest state changes demand them. The repository's static-state work contains multiple independent fast paths and should not be reintroduced as one bundle. QEMU translator, research history.

Implementation. Identify the precise redundant key/state derivation or missed legal chain. Cache the complete relevant identity, not just the PC. Preserve segment/privilege/address-space state, code invalidation, debugger/plugin requirements, exceptions, and interrupt-observation boundaries. Constant state must be demonstrated over the proposed reuse interval.

Expected gain model. If dispatcher work occupies fraction p of the serial critical path and becomes s times faster, whole-path speedup is 1 / ((1-p) + p/s). At an assumed 34% and 2× local improvement, that is 1.2048×, not 2×. This is an illustrative model, not a current profile claim.

Acceptance. Differential CPU state and memory after controlled instruction sequences; self-modifying code, page changes, exceptions, interrupt-unmask transitions, and cache invalidation; then fixed guest-work retail A/B. Optimizing dispatch and improving generated guest code are separate hypotheses.

First patch boundary

Do not remove required exits or relevant state-key bits. Treat direct chaining and cached key derivation as different candidate changes.

full relevant guest CPU/code identity -> valid TB hit/chain -> required exit and interrupt observation

Locate the inspected seam before editing; names or ownership may have changed since the pinned review:

git grep -n -E 'cpu_get_tb_cpu_state|tb_lookup|tb_find|goto_tb|lookup_and_goto_ptr' -- accel/tcg target/i386

Proposed focused tests

These are implementation gates to add or exercise, not claims that production tests already exist or passed. Retained standalone checks are on the checks page.

Test ID	Setup / deliberate control	Required oracle
C01.01	Identical program counter under each relevant privilege/address-space/static-state change.	The correct TB is selected; stale identity is not reused.
C01.02	Self-modifying code, remapping, exceptions and interrupt/budget exits around a proposed chain.	Invalidation and required exit/observation boundaries remain effective.
C01.03	Fixed instruction/event work on control and candidate with lookup/chaining counters.	Local dispatch reduction and end-to-end CPU/guest progress are reported independently.

Counters and rejection criteria

Collect: tb_lookups, tb_hits, chained_transfers, dispatch_cpu_ns, generated_code_ns, invalidations, guest_instructions, exit_reasons. Keep exact counts separate from sampled durations; use an uninstrumented build for performance qualification.

Reject or hold: Reject an incorrect TB or delayed required interrupt. The assumed 34%/2x Amdahl scenario is a model, not a current measured opportunity.

Follow the common protocol for source identities, previous-main/fixed-baseline controls, raw results, confidence and retail/XISO qualification. No gain becomes proven from a model, cache hit, local operation count, or shifted wait label alone.