# DF-5581 — Intel graphics stolen-memory reservation is compiled out; drm/i915 trusts unreserved firmware values

## What to run

```
dfbsd-qemu/vm.sh status            # must be 'up' (vm.sh up otherwise)
sh probe.sh                        # on the host: the equivalent commands are
                                   # vm.sh run_user / vm.sh run_root sequences
```

The decisive run captured in `run.log`:

```
dfbsd-qemu/vm.sh run_user  'id; sysctl hw.intel_graphics_stolen_base hw.intel_graphics_stolen_size'
dfbsd-qemu/vm.sh run_root  'pciconf -l | grep pci0:0:2:0; \
                            grep -rn phys_avail_reserve /usr/src/sys/ --include=*.c --include=*.h; \
                            kldstat | grep i915'
```

## Expected output (on the QEMU rig)

* `hw.intel_graphics_stolen_base: 0` / `hw.intel_graphics_stolen_size: 0`,
  readable by `uid=1001` — the sysctl surface is world-readable; the quirk is
  inert here because the VGA at 0:2:0 is Bochs/QEMU (`chip=0x11111234`,
  vendor 0x1234), which the vendor gate at `pci_early_quirks.c:288` rejects.
* The full-tree grep returns exactly ONE hit: the commented-out call at
  `pci_early_quirks.c:309` — no reservation mechanism exists anywhere in
  `sys/`.
* `i915: not loaded` (no Intel GPU).

## Why this is the finding, not a negative

The finding is a *code-proven* defect, not a guest-runtime one:

1. `pci_early_quirks()` (called from `init386()`, `machdep.c:2760`, before
   `cninit()`) computes the Intel stolen-memory base/size from
   firmware-programmed config registers — **the stated purpose is to reserve
   that range** (`pci_early_quirks.c:264-271`).
2. The reservation is commented out (`:308-310`) and `phys_avail_reserve`
   does not exist anywhere in the tree (live-proven on the guest's full
   `/usr/src`; include also commented at `:35-36`).
3. `i915_module.c:18-30` copies the values into `intel_graphics_stolen_res`;
   `i915_gem_stolen.c:414-417` adopts them as the GPU-exclusive `dsm` range
   and allocates GPU objects from it.
4. The only overlap guard, `devm_request_mem_region`, is a DragonFly stub
   (`i915_gem_stolen.c:85-102`) that manages a **static rman containing only
   the requested region itself** — it cannot detect any conflict and always
   succeeds. The Linux conflict semantics are gone.

Net effect: on the exact buggy-BIOS platforms the quirk exists for (firmware
did not hide stolen memory from the OS memory map — or BSM/GMS disagree with
the memory map), the kernel page allocator and the i915 stolen allocator own
the *same physical pages*. GPU writes to stolen objects silently corrupt live
kernel memory.

The QEMU rig cannot manifest this: QEMU has no Intel VGA device model, so
0:2:0 can never read `8086:<table id>` without patching QEMU itself — a
documented hard blocker (see `VERDICT.md`). Code-reading is decisive here.