From c17da06d6cd8b9c69449904637bf37729a962989 Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Fri, 2 Oct 2026 11:28:49 -0400 Subject: docs: engineering-operations playbook and project-wide status accuracy pass - 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). --- docs/09-reference/glossary-and-faq.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) (limited to 'docs/09-reference') diff --git a/docs/09-reference/glossary-and-faq.md b/docs/09-reference/glossary-and-faq.md index e0c68f6..1668e35 100644 --- a/docs/09-reference/glossary-and-faq.md +++ b/docs/09-reference/glossary-and-faq.md @@ -97,16 +97,24 @@ MIG is a hardware partitioning mechanism; Open-IOV's scheduling policy can use it where available. It is part of the multi-tenancy work. **How fast is it?** -No published numbers yet: execution forwarding is not implemented, and even -the initialization path has not been measured under the project's methodology. -Any performance claim will come with the methodology and the measurements -together (see +No published numbers yet: copy-engine-class work forwarding and engine-authored +release + fault relay are implemented but default off, and GR/kernel execution +is still the open frontier; even the initialization path has not been measured +under the project's methodology. Any performance claim will come with the +methodology and the measurements together (see [`../05-operations/01-performance-correctness-security.md`](../05-operations/01-performance-correctness-security.md)). **Where do I report bugs or ask for help?** Open an issue with the standard captures listed in the debugging document. A reproduction plus logs is worth more than a description. +**Can I run the live hardware cycles?** +Live physical-backend cycles are supervised only — one at a time, never +unattended — and a system is never rebooted without a written reason, a +post-reboot plan and explicit human approval. The operational detail is in the +engineering-operations document, Part II +([`../eng-ops.md`](../eng-ops.md)). + **Can my company use this commercially?** Yes, under BSD-3-Clause (kernel modules GPL-2.0), with no fee. We also welcome co-development; see the ecosystem document. -- cgit v1.2.3