guest-diag: widen PB_GL_FAMILIES GL setup-push window to 0x4300000 (the setup push moved to 0x4250110)

1 files changed, 14 insertions, 1 deletions

diff --git a/tools/guest-diag/guest_pin_stream.py b/tools/guest-diag/guest_pin_stream.py
index a645a86..e98d851 100644
--- a/tools/guest-diag/guest_pin_stream.py
+++ b/tools/guest-diag/guest_pin_stream.py
@@ -1460,8 +1460,21 @@ PB_CE_HI = 0x121000000
 # original families did not cover, so the content resolver answered
 # nothing and the read lottery could never be won for it (the
 # 0x4020000-family hold re-armed for its whole 20 s window).
+# SESSION 153-R1394: the r1390/r1393 boots' setup push moved to
+# va=0x4250110 len=12288 (context push 0x4217014), past the 0x4210000
+# end of the r1117 window, so the same silent family miss left entry 9
+# unreadable (~337 `skipping stale entry` repeats). Widen the third
+# family to 0x4200000..0x4300000. Base stays 0x4200000, so the identity
+# k=(va-base)>>12 for the moved setup push is 0x50 and the search
+# neighbourhood is unchanged (same rule as the r1117 push at k=0).
+# RISK (bounded, noted): the widened window spans several allocations and
+# _gl_fam is keyed on the shared base, so a loose resolver hit for a
+# second allocation (e.g. 0x4217014) may be served from the first
+# allocation's learned (area, adj) with no content check. The strict
+# anchors (full host parse via resolve_va_strict) and the loose-deferral
+# in the want-file walk remain the gate for those VAs.
 PB_GL_FAMILIES = ((0x3200000, 0x3300000), (0x4000000, 0x4100000),
-                  (0x4200000, 0x4210000),
+                  (0x4200000, 0x4300000),
                   (0x42000000, 0x43000000))
 # m165 (D-F1a): UVM semaphore-pool page range. The pool is a 4 KB sysmem
 # uvm_rm_mem placed by the UVM arena right after the 16 MB CE push buffer;