docs: architecture rewrite - emulate vs pass-through model, phased performance roadmap

- Clear separation: EMULATE (GSP interface, BARs, config) vs PASS-THROUGH
  (compute, memory, DMA to physical GPU)
- Phased roadmap: Phase 1 (GSP-RM correctness) → Phase 2 (memory model) →
  Phase 3 (compute forwarding) → Phase 4 (performance) → Phase 5 (graphics)
- Host module architecture corrected: apt nvidia (570.211.01) for physical
  GPU, open-iov-vfio.ko for vGPU emulation, NO 610 submodule
- Host stability guarantees documented (BAR3 shadow, submodule skip)
- GSP_EMULATION_ARCHITECTURE.md: memory model corrected (BAR1/BAR3 shadows)

1 files changed, 17 insertions, 8 deletions

diff --git a/docs/GSP_EMULATION_ARCHITECTURE.md b/docs/GSP_EMULATION_ARCHITECTURE.md
index eb7f697..8da8f49 100644
--- a/docs/GSP_EMULATION_ARCHITECTURE.md
+++ b/docs/GSP_EMULATION_ARCHITECTURE.md
@@ -116,14 +116,23 @@ implementation** when `gsp_rpc_emulation_is_enabled()` (set once per mdev by
 > RPC loop plus multi-second stalls. Emulation mode now fails these fast with
 > `pr_warn_ratelimited`.
 
-### Memory model caveat (design note)
-
-Guest VRAM (BAR1) is mapped **directly to the host GPU's physical BAR1** (gpa).
-`gsp_rpc_alloc_emul`, however, services ALLOC with *host system pages* DMA-mapped
-to the physical device. These two models are not yet unified: a guest allocation
-returning `gpu_va=0x100000000+` is not visible through the guest's BAR1 window.
-This is a known design gap to resolve before CUDA workloads; it does not affect
-driver probe/GSP boot, which is the current milestone.
+### Memory model (corrected 2026-09-22)
+
+Guest BAR1 (VRAM aperture) is backed by a **dedicated host-RAM vzalloc buffer**
+(256 MB, `bar_init.c`), NOT the host GPU's physical BAR1. Guest VRAM accesses
+hit our clean host-RAM backing. This is a placeholder — for real CUDA compute,
+the memory model must evolve (see `refactored-architecture.md` Phase 2):
+
+- **Current (Phase 1)**: Guest VRAM = host RAM (safe, no host GPU corruption).
+  Guest driver probes but cannot compute.
+- **Phase 2**: Guest VRAM backed by DMA-coherent host memory or physical GPU
+  VRAM partition (required for CUDA).
+- **Phase 3**: Guest channel/pushbuffer work forwarded to physical GPU
+  channels (required for compute).
+
+Guest BAR3 (instance memory window) is also a **vzalloc'd shadow** (32 MB,
+`bar_init.c`), NOT the physical GPU's BAR3. Guest BAR3 writes must not reach
+the host GPU's instance memory (root cause of host GSP crash, fixed `85d0668`).
 
 ---