diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-08 12:22:35 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-08 12:23:37 -0400 |
| commit | ecb5953baa5af98a20abdc2a427ee25245fc687e (patch) | |
| tree | 5a0b7b592290b4d48d3f06860ec06f376ccb2cf7 /scripts/test_windows_guest.sh | |
| parent | b232f7d82c699c4a1e922a0d045337d29dab824b (diff) | |
| download | open-iov-ecb5953baa5af98a20abdc2a427ee25245fc687e.tar.gz open-iov-ecb5953baa5af98a20abdc2a427ee25245fc687e.zip | |
vgsp-sema: FB-aperture GR ring discovery + per-registration discovery re-arm (FORENSICS-grv1 R1)
FORENSICS-grv1: the grv1 campaign ran the H1 content pass to its 60-pass cap
with zero pairs. svc_read() is vfio_dma_rw over guest DMA addresses, so the
4 GiB guest-RAM scan found all eight GR ctx-init push candidates (len 0x2a4)
but no page-aligned ring entry0; the ring lives in the emulated vidram
aperture (vgpu->bars[1].vaddr), where m104's green ring was FB
0x140000 + R*0x3000. The trusted walk also missed (the ring VAS is
unpublished: VAS[0] root empty, VAS[1] has no usable PD0 for the window), and
the H3 early publish was a no-op (put=0 from the pool-relative registered
USERD at 0xc32000, which reads zeros in FB).
Changes (one coherent commit):
1. svc_gr_content_pin() takes the ring's aperture. The ring page and the
USERD at ring+0x2000 are read through that aperture; the push page and its
release group stay guest RAM (SYS); the hot-page bitmap (guest-PA indexed)
is only touched for a SYS ring. FB rings log
"content-discovered GR ring ... -> fb 0x...", RAM rings keep "-> pa=...
ap=1". The gate is unchanged: entry0 exact (push VA + len), push parses
end-to-end, release group exactly at len-20 with this rank's slot and
payload 1, USERD readable (active pair or readable idle) - otherwise
nothing is pinned.
2. svc_gr_content_discover() scans the emulated VRAM mapping after the RAM
pass for every rank that has a RAM push candidate but no guest-RAM ring
candidate, at a page stride, bounded to SVC_GR_CONTENT_FB_LIMIT (512 MiB,
matching the existing one-shot fbs scan bound), with the same entry0
filters and the plausible-tail check. Candidates pair with the RAM pushes
by length (0x2a4) and rank geometry, then go through the same full gate.
3. The 60-pass one-shot cap is now a per-epoch bound that re-arms on channel
registration: gsp_sema_service_channel_add() sets svc_gr_content_rearm for
GR channels (the guest recreates channels on every context retry), and
svc_gr_content_discover() consumes it and resets the epoch pass count. The
cap message is ratelimited and names the re-arm condition, so discovery
can no longer retire for the boot while the guest is still trying.
4. The registered userdMem base (pool-relative, reads zeros) is superseded by
the ring+0x2000 USERD probe through the ring's aperture; this covers the
grv1 "probe rc=-11 from the wrong base" case without a separate path.
No module parameters added or changed; the accepted recipe is untouched.
Evidence: FORENSICS-grv1 sections 0-5, m104 17-host-m104-r1.txt:164/169,
11-hostdmesg-grv1-r1.log:2308/2339-2347/2429-2435/2796.
5. The GR pin-branch "auto-pinned GR ring ..." line now carries ap=%d, so
the latch is unambiguous in dmesg (FB=2 for the content-discovered ring).
Diffstat (limited to 'scripts/test_windows_guest.sh')
0 files changed, 0 insertions, 0 deletions
