summaryrefslogtreecommitdiffstats
path: root/kernel/ioctl.c
diff options
context:
space:
mode:
authorArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-08 11:57:59 -0400
committerArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-08 11:58:05 -0400
commit8c72fa6aa5547ff6ee2452b0ff58e2a71124b1f4 (patch)
treeef5a9658d6eec2b303fb42738cdc8625f20cf64c /kernel/ioctl.c
parentbd029a10344e7cf27cf4bee123ca88ef84e73094 (diff)
downloadopen-iov-8c72fa6aa5547ff6ee2452b0ff58e2a71124b1f4.tar.gz
open-iov-8c72fa6aa5547ff6ee2452b0ff58e2a71124b1f4.zip
vgsp-sema: kernel-native GR ring/USERD discovery (both apertures, trusted walk, content fallback) (FORENSICS-v2 H1+H2)
The v2 campaign confirmed the CE-side fixes work (89/89 releases applied, pool page resolved src=trusted) but the stall moved one phase later: the guest authors its eight GR context-init pushes and the host never reads a single GR GPFIFO entry (ring_auto=6 CE-only, pub_calls=0, gr_rel=0, work_gr req=0). The GR ring VA 0x200200000+R*0x3000 and its USERD are never resolved: svc_gr_ring_autopin only tried FB conventions, userd-derived FB candidates and existing pins (FORENSICS-v2 H1/H2). Three bounded, content-gated extensions: 1. Trusted walk (H1): try svc_lookup_trusted() for the ring VA - the driver-published VAS walk / self-discovered directory chain that resolved the CE pool page in v2 ("pool-pa ... src=trusted", 11-hostdmesg-v2-r1.log:2313). 2. Both apertures (H2): every ring-derived and registered USERD candidate (svc_chan_userd) and every userd-derived GR ring candidate (svc_gr_ring_autopin) is tried in the registered aperture first and the other one second; v2 read the GR USERD through FB and got 0/0 while the same boot's pushbuffer pins are sysmem. 3. Content fallback (H1 last resort): one self-gated, 2 s-rate-limited, 60-pass-capped 64 KB chunked scan of registered guest RAM locates, per rank 0..7, the release-group page ("200426c0 00000002 0400ffXX 00000001", group at push len-20, page-aligned push at VA 0x200400000+0x400000*rank, m104/handoff 2576-2597 geometry) and the ring page whose entry0 is the exact (push VA, len) pair. A pair is pinned only when the full gate passes: entry0 bytes exact, the push parses end-to-end as a method stream, the release group is exactly at len-20 with this rank's slot and payload 1, and the USERD at +0x2000 reads a plausible get/put pair (or a readable idle 0/0). Anything else pins nothing. All candidates share the existing rule: a wrong guess costs a failed probe, never a wrong pin. Evidence: FORENSICS-v2 H1/H2, m104 17-host-m104-r1.txt:169-171, v2 dmesg 11-hostdmesg-v2-r1.log:2313-2714.
Diffstat (limited to 'kernel/ioctl.c')
0 files changed, 0 insertions, 0 deletions