Click a patch. Blue outline = what it needs
(ancestors); vermilion = what needs it (descendants). Click again or press
Clear to reset.
Legend
verified dependency
inferred (verify during group review)
dotted purple arrow, hollow head: no regression — the later patch works without the earlier one, but without it would degrade another feature (named on hover), so the earlier one goes first
gold arrow: completes an end goal (hexagons). Each goal is drawn beside the group that achieves it; together the end goals constitute the ASI end state (guest-owned data not reachable from other contexts). The gold octagon, Performance, is what group O achieves; it is not part of the ASI end state.
green node border: vetted so far (status shown on selection)
double border: posted to xen-devel (thread link on selection)
blue border and ✓ in the label: carries a Reviewed-by (tags shown on selection)
Dependencies already implied by a drawn path are recorded but not drawn; the click-cone includes them.
Groups
VH — Per-vCPU area and mapcache for HVM: d02–d14 (13 patches)
DV — Sparse directmap view: d15–d24 (10 patches)
X1 — vCPU state window and its consumers: d25–d31 (7 patches)
X2 — Register state behind the window: d32–d35 (4 patches)
PH2 — Per-pCPU stacks for HVM: d55–d65 (11 patches)
O — Performance optimizations: d67–d73, d76 (8 patches)
Debug — Debug keys and counters: d74–d75 (2 patches)
VH = per-vCPU area and mapcache for HVM domains, DV = a sparse view of the directmap, alongside the full one, chosen per domain at creation, X = key per-vCPU structures off the xenheap, into a per-vCPU state window in the per-domain area, in four groups: X1 the window and its first consumers, the SVM VMCBs and the VMX guest MSR lists; X2 every guest vCPU's saved register frame and the HVM emulator's operand caches; X3 map_domain_pages(), which maps several pages in the calling vCPU's per-domain area, used in place of vmap() by two emulation paths; X4 the guest XSAVE areas, with the FPU changes ahead of them, PH = per-pCPU stacks for HVM domains, in two groups: PH1 the preparation, rendezvous data and call-function IPI payloads off the stack; PH2 the stacks themselves: each pCPU's stack at a per-CPU address in the per-domain area, a cpu-stack vCPU's page-tables mapping only its own pCPU's, the stacks allocated from the domain heap and zeroed on context switch, and three stack checks that could be dropped, O = performance optimizations: paging-pool pages kept in the sparse view (the HAP pool; the shadow pool as an [RFC]), their removal batched; fewer guest page walks and p2m lookups for HVM guests; and, as an [RFC], the sparse view's flushes sent only to the CPUs that may hold its translations; the two [RFC]s are at the end of the series, Debug = aids for testing: [DEBUG] patches, not for committing, that count the sparse view's flushes and audit it with a debug key. Numbered in series order within a letter;
the series runs VH DV X1 X2 X3 X4 PH1 PH2 O Debug. Ranges are positions in this revision of the
page.
Postings
part 1 (Aug 2026) — nodes d25: cover letter (threads via the sidebar; links resolve on lore once posted)
part 2 (Sep 2026) — nodes d03–d07, d09, d25: cover letter (threads via the sidebar; links resolve on lore once posted)
v3 (Oct 2026) — nodes d01, d03–d07, d09, d11–d15, d18–d22: cover letter (threads via the sidebar; links resolve on lore once posted)
v4 (Oct 2026) — nodes d01–d15, d18–d31: cover letter (threads via the sidebar; links resolve on lore once posted)
v5 (Oct 2026) — nodes d01–d45: cover letter (threads via the sidebar; links resolve on lore once posted)
Open items
This page maps the series: v5, posted on 28 Oct 2026 (d01-d45, 45 patches), and the patches implemented to follow it, not yet posted. The groups are those of v5's cover letter: VH, DV and X1, posted before, and X2, X3 and X4, new in v5; after them PH1, PH2 and O (the Groups list gives each one's patches). Posted patches are drawn with double borders, their threads linked on selection (v3 of 7 Oct 2026, v4 of 19 Oct 2026, v5); the Postings list gives each posting's nodes. Reviewed-by and Acked-by tags are marked on the patches that carry them.
Since v4: v4's 16/30 is now two patches, d17 and d18, with part of it moved into d15; d16 is new, a work-around for a slow-down in dom0 kernel decompression once a sparse view is configured; and v4's 26/30 is dropped, replaced by Ross Lagerwall's "x86/svm: Don't clear clean bits on every context switch", now in staging. The perdomain interface changes, the asi= option and the per-vCPU L3 (d03-d07, d09) were posted before, as part 2 v2 08-12 and 14, and populate_perdomain_mapping() (d25) as part 1 02 and part 2 v2 02, here in a cut-down form; their thread links are kept.
Group O collects performance optimizations (d67-d72, d73, d76): paging-pool pages kept in the sparse view (the HAP pool, and the shadow pool as an RFC), with their removal at teardown batched; fewer guest page walks and p2m lookups for HVM guests; and, as an RFC, the sparse view's flushes sent only to the CPUs that may hold its translations. Their goal, Performance (the octagon), is not part of the ASI end state. DV ends with two fixes for xenheap frees on the sparse view (d23, d24). The Debug group (d74, d75) holds two patches, not meant for committing, that count the sparse view's flushes and audit it with a debug key.
Node numbers are written dNN and name positions in the series order shown here; they are stable within one revision of this page. d01-d45 are v5's 01-45; the patches after them follow from d46, in the order planned for posting them.
This graph is a work in progress: it maps the posted series and the patches planned to follow, and dependency lines (especially dashed ones) may still change as the patches are reviewed.
Posting model: a rolling series. Patches are posted from the front as they become ready and dropped once committed; new ones are appended as they mature. "A later patch" in a message may therefore mean "next round in this series".
Edges are logical dependencies -- an edge means the pair cannot compose in the other order without redesign -- plus a few purpose edges ("A exists to make B reviewable") and no-regression edges (dotted purple: B works without A, but without A it would degrade another feature, named in the edge's tooltip, so A goes first). Dashed edges are inferred from titles/messages and should be confirmed as their groups are reviewed.
Source of truth: gen-depgraph.py (same directory);
positions read live from stg series; regenerate with
python3 gen-depgraph.py.