diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-11 15:43:30 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-11 15:43:30 -0400 |
| commit | 1743c19465f4c024010d37e1fd96e9192cdc4525 (patch) | |
| tree | 2cdd63b2e6e7b8c194b7e031ceeb8ef0e4d20473 /kernel/firmware_analyzer.c | |
| parent | 3d4777f614e31f3c3a4f2ce49b37054a10fd1fd3 (diff) | |
| download | open-iov-1743c19465f4c024010d37e1fd96e9192cdc4525.tar.gz open-iov-1743c19465f4c024010d37e1fd96e9192cdc4525.zip | |
vgsp-sema: bound emulated-vidmem shadow accesses by the shadow size, not the BAR1 aperture (ISSUE-0002)
The pma scrub in a second/third CUDA session memsets a legitimate vidmem
offset at 262M (inside the 512M turing shadow) and the copy path rejected it
with -EINVAL because every FB bounds check compared against
vgpu->bars[1].size, the physical BAR1 aperture exposed to the guest (256M on
TU104). The op was held and retried forever (opdef), the GR scrub waited in
scrubCheckAndWaitForSize and the client froze.
All bounds checks that guard a dereference of the emulated vidmem shadow at
vgpu->bars[1].vaddr now use nv_vgpu_fb_emul_size() via svc_fb_shadow_size():
the copy/fill paths, svc_read_ap/svc_write_ap, svc_ap_ok, the page-directory
discovery scans, svc_lookup's vidmem VA translation, the GRCE inline write,
svc_fwd_operand_hpa and the debug scans. The 2 MB leaf path of svc_gmmu_walk
now validates through svc_ap_ok like every other leaf path so an
out-of-shadow translation falls through to the shadow fallback instead of
reaching the copy path. The RM page-directory debug peek is bounded the same
way.
Evidence: r75b live log: sema-bigcopy dst_va=0x76aa08e02200 -> pa=0x10602200
ap=0 prov=3; sema-bigop rc=-22 repeated; guest sysrq stack
scrubCheckAndWaitForSize -> pmaAllocatePages.
Diffstat (limited to 'kernel/firmware_analyzer.c')
0 files changed, 0 insertions, 0 deletions
