| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
across the tree
New page docs/04-implementation/03-execution-frontier.md describes the chain
that must fire for a guest CUDA launch (guest push -> GPFIFO/front-end ->
inline launch-descriptor install -> engine read/dispatch -> completion),
where the leading edge is (the descriptor install path), how we know
(front-end vs engine-authored observables and their limits), what is
exonerated (context validity at dispatch, destination window mapping,
fetch alignment, shared-buffer rule, parenting), the ranked issues (verbatim
prelude targets, missing descriptor-virtualization control, sentinel
hygiene), live investigation lines and labelled theories.
Align every page that still said GR execution is blocked on engine-context
validity to the current frontier, and add the new page to the README reading
order (row 15, later rows renumbered). Docs only; no code.
|
| |
|
|
| |
on one page
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- docs/eng-ops.md gains Part II, live physical-backend engineering
operations: hard rules, the full module-parameter matrix, the routine
supervised cycle and clean-release checklist, the debugfs inventory,
how to read gsp-phys-state, a debugging scenario catalogue
(CTXNOTVALID/promote wedge, fail-safe WPR2, unload hangs, guest wedges,
MMU/PTE and PBDMA faults, relay symptoms), a hazard register (crash
causes and debugging side effects), the physical-backend OODA loop, and
the work-context map with porting flows
- architecture, implementation, operations, orientation, getting-started,
portability, ecosystem and reference docs corrected to the current
state: CUDA driver-API smoke green, CE-class work forwarding and
engine-authored releases plus fault relay in place (default off), GR
execution blocked on engine-context validity, the promote wedge and
designed locked fail-safe, and P5 wave-2 subsumed
- internal-reference cleanup in tracked docs (no analysis-source or
local-archive references); historical architecture document bannered
- README reading list and STATE-CURRENT frontier refreshed; new pages
(runbook, green-eye user guide, porting sequence, porting/packaging
notes) linked from the tree
Link check: scripts/check-docs-links.py passes (56 files, no broken links).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
copies
- new default-off gsp_phys_work_defer_release: a forwarded guest push's
releases are recorded and its GPFIFO entry is held (no consume, no
GP_GET write, no counter publish/stall) until the work item publishes
completion; the service thread then delivers the releases, with a
fallback on failure/timeout (500 ms cap enforced every pump pass)/
pause/quiesce/channel-delete
- new default-off gsp_phys_work_hw_primary: the software copy is skipped
for forwarded ops, so the physical engine authors the data; a once-only
software copy runs before the releases on any hardware failure or when
the request cannot be queued
- release-apply helpers extracted; exactly-once latches; channel-delete
and teardown handling; counters and a work_guard state line
- live: deferred-release run engaged=75 applied=75 timeouts=0 with the
full smoke green; hardware-primary run req=100 ok=100 verify_ok=100
fallback=0 copy_skipped=119 copy_fail=0, smoke ALL OK 64/64 (guest read
data the engine authored), with 19 fail-closed inline software
fallbacks under single-inflight contention; a range-unregistered run
proved the fallback (121 skipped copies, all recovered, smoke green)
- defaults off; the software path and all existing guards unchanged
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- the sema service captures the first eligible copy per push from the
software resolver's own operands (the real push shape mixes guest RAM
with emulated-VRAM shadow addresses, including physical destinations)
- HPA resolution: guest RAM through the shared guest-RAM file page cache,
emulated VRAM through the mapping of its kernel shadow
- new scratch page-table pool: 16 zeroed page-table pages with their
page-directory entries built before any engine access, handing out one
whole 128-byte GMMU PTE fetch line per copy pair (16 PTEs, 512 pairs
per boot, never reused; a PTE written into an already-fetched line is
not observed and there is no invalidate path)
- the backend submits the copy on the module-owned channel and verifies
the result host-side; every miss falls back to the ladder shadow copy,
and the software pump remains authoritative
- live (full smoke, both parameters on): req=42 ok=42 verify_ok=42
verify_fail=0 fallback=0, guest payload roundtrip ALL OK 64/64,
clean latched release; defaults stay off
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- file-backed guest RAM (launcher memory-backend-file share=on) and
in-kernel GPA->HPA translation through the shared file page cache
(read_cache_page + page_to_phys + pfn_valid), opened O_LARGEFILE;
new default-off gsp_phys_guest_mem parameter
- debugfs gsp-phys-guest-ram (path + gpa/off/size ranges) and
gsp-phys-guest-gpa (one pinned GPA per boot); rm-call triggers 6/7 run
host->guest and guest->host 4 KiB CE copies; trigger 8 is a PTE
self-test through a fresh slot
- guest page-table slots are pre-built during ladder stage 3: runtime
PTE writes into an already-walked page-table line are not observed
without a TLB invalidate
- guest RAM layout (q35 4.2, 4 GiB): below-4G GPA == file offset,
above-4G offset = GPA - 0x80000000 (2 GiB PCI hole)
- tests: tools/test/gpage_test.c guest probe; docs + STATE-CURRENT
record the live green (G2H/W2G with semaphore release, guest observed
the write, smoke ALL OK 64/64, clean latched release)
|
| |
|
|
| |
P5 wave-1 shadow execution
|
| |
|
|
|
|
|
|
| |
- STATE-CURRENT snapshot moves to the P3 frontier: the host-freeze latch
and readiness gates are validated, the static identity overlay and the
read-only control forwarding are landed and live-verified
- the physical-backend guest-wiring design is now marked P0-P3 implemented
with the P2/P3 acceptance results
|
|
|
physical-backend guest-wiring design
- STATE-CURRENT snapshot 2026-10-01 21:05: the host RM-client ladder now
allocates VAS+PDB+TSG+channel and executes a real 4 KiB VA-mode CE copy
(semaphore released, dst==src) on the physical engine; next is wiring the
live session into the guest-facing mdev/vfio path.
- docs/03-architecture/11-physical-backend-guest-wiring.md: phased design
(P0-P6) for bridging the physical backend into the guest-facing emulation,
with the seam table, lifecycle changes and static-config flow.
- docs/README.md: reading order updated for the new document; execution
status refreshed.
|
