summaryrefslogtreecommitdiffstats
path: root/tools/rmtop/include
diff options
context:
space:
mode:
authorArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-25 06:24:37 -0400
committerArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-25 06:24:37 -0400
commita3d1a585735b8add2b072feeebfc483d84bf5b45 (patch)
tree4a79afe70d43d7127b60164ea609f2f4fb78ddd4 /tools/rmtop/include
parent9813c9b9b6d9fa7e56fe0e77ccd4589fd9e90902 (diff)
downloadopen-iov-a3d1a585735b8add2b072feeebfc483d84bf5b45.tar.gz
open-iov-a3d1a585735b8add2b072feeebfc483d84bf5b45.zip
r679: 0x2080a097 handler with runtime-tunable reply words (wall-2 session 75)
The guest Vulkan client (libnvidia-eglcore) issues RM control 0x2080a097 in a ~1.8 s retry loop while its engine-readiness check stays negative; the bare-metal oracle (same client on the host with the real driver) never issues it, so it is a vGPU-only path (engine type 0xe00101). The handler echoes the 1168-byte in/out record block and applies three module parameters - wall2_a097_flag/v488/v48c - so one boot can sweep reply variants without rebuilding (the client reads params +0x204, +0x488, +0x48c back; file offsets 0xecd45f..0xecd475 in libnvidia-eglcore.so.570.144). Sweep result so far: flag=1 with v488=0 or 1 does not stop the retry; the readiness wait lives in the client's engine loop (0xd6ef40..0xd6f0ab polling byte +0x1b038 of the engine object, recomputed by a91ea0 from engine-state fields), so the missing state is deeper than the reply words.
Diffstat (limited to 'tools/rmtop/include')
0 files changed, 0 insertions, 0 deletions