summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-02 00:39:56 -0400
committerArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-02 00:39:56 -0400
commit7d0601397abdad813ca93ff9a2bd8cc5a2782879 (patch)
tree084d998c9d80e4e707ab5b9debe3abaf53ec0536
parent2ccd9f875e53f8c9a98bfea47dc2657f3d3a1d6a (diff)
downloadopen-iov-7d0601397abdad813ca93ff9a2bd8cc5a2782879.tar.gz
open-iov-7d0601397abdad813ca93ff9a2bd8cc5a2782879.zip
docs: gate post-1.0 host acceleration as do-not-implement
Clarify in the post-1.0 record and the public status page that host-native acceleration / host display is a stretch goal we are only considering: do not block on it, pursue it, or design around it. It is never reached automatically, requires an explicit human decision after all baseline goals are complete (and only once there is no known risk), and may be scrapped on architectural grounds. No aspect of the baseline software may be designed toward it. No baseline design or code changes.
-rw-r--r--STATE-CURRENT.md25
-rw-r--r--docs/10-post-1.0/experimental-host-acceleration.md20
2 files changed, 40 insertions, 5 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index fd737c7..622f997 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -550,11 +550,26 @@ progress.**
## Deferred goals
- Host NVIDIA driver (`nvidia.ko`) over a virtual function — host OS
- acceleration from the open-iov device model — is a **deferred design goal**,
- lower priority than guest CUDA execution, multi-VM, 3D and performance; the
- verdict (not possible on this platform as-is) and a first design sketch are
- in
- [`docs/03-architecture/12-host-vf-acceleration-future-goal.md`](docs/03-architecture/12-host-vf-acceleration-future-goal.md).
+ acceleration / host display from the open-iov device model — is a
+ **post-1.0 stretch goal we are still only considering**. We may work on it at
+ some point; we will probably take a crack at it because it is a great
+ feature, but **do not block on it, pursue it, or design around it**. It is
+ strictly lower priority than every baseline goal (guest CUDA execution,
+ multi-VM, 3D, Windows, isolation, performance, portability). It is
+ **never pursued automatically**; it requires a human decision once we are
+ certain there is no risk — which we are not certain of now — and it may be
+ scrapped on architectural grounds. Treat it until further notice as
+ **do not implement**.
+ - First design (`13-host-vf-acceleration-design.md`) was written and then
+ **reverted on 2026-10-02** after independent reviews falsified its
+ load-bearing mechanisms; all associated doc edits were reverted.
+ - The corrected record, candidate approaches, experimental gating policy and
+ revisit criteria are in the post-1.0 document
+ [`docs/10-post-1.0/experimental-host-acceleration.md`](docs/10-post-1.0/experimental-host-acceleration.md)
+ (intentionally not linked from the docs front door and not part of the
+ active reading order; don't index it and don't design toward it).
+ - Earlier verdict and options:
+ [`docs/03-architecture/12-host-vf-acceleration-future-goal.md`](docs/03-architecture/12-host-vf-acceleration-future-goal.md).
## Environment
diff --git a/docs/10-post-1.0/experimental-host-acceleration.md b/docs/10-post-1.0/experimental-host-acceleration.md
index c88bcaa..38b9774 100644
--- a/docs/10-post-1.0/experimental-host-acceleration.md
+++ b/docs/10-post-1.0/experimental-host-acceleration.md
@@ -13,6 +13,22 @@
> 2026-10-02 after independent adversarial, soundness, and VM-risk reviews
> falsified the first design. The review record is kept privately.
>
+> **How to treat this goal (from the owner, 2026-10-02).** We are *considering*
+> doing this; we may do this at some point. We will probably take a crack at it
+> because it is a great feature — but **do not block on this, do not pursue it,
+> and do not design around it.** It will be important to try at some point, but
+> primary objectives and the other stretch goals come first. Only when we are
+> certain there is no risk — which we are not certain of now — will we make a
+> **human decision** to proceed. This is **never pursued automatically**.
+> Consider it, until further notice, **deferred**.
+>
+> **Do-not-implement rule (binding).** Treat this document and the goal it
+> describes as **"Do not implement"** until after *all* design goals are
+> reached — and even then the goal may be scrapped on architectural grounds.
+> No aspect of the software may be designed toward a forward-looking goal that
+> would support this experimental feature: no new abstractions, hooks, seams,
+> parameters, or "just in case" code for it, anywhere in the baseline system.
+>
> **Experimental policy (binding when the time comes):** any host-acceleration
> work is experimental; it may only be built behind a compile-time flag and
> enabled by an explicit module-load flag; it must not alter, replace, or
@@ -387,3 +403,7 @@ Until then, this document is dormant.
* **Policy:** do not implement unless the user explicitly asks; when
implemented, it is experimental, compile-time gated, module-load gated,
duplicate-path, and reversible; the baseline system is never compromised.
+ The goal is **never pursued automatically** — it requires an explicit human
+ decision after every baseline goal is complete and we are certain there is no
+ risk — and it may be scrapped on architectural grounds. Until then, no aspect
+ of the baseline software may be designed toward it.