From 6aadb593750736f239fd54a0ccef4b3834c08fc4 Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Mon, 21 Sep 2026 18:01:55 -0400 Subject: kernel: GSP-RM msgq emulation + TU104 hardware tables (GET_GSP_STATIC_INFO, GSP_RM_CONTROL) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Implements the GSP-RM reply content layer for the msgq RPC channel: - kernel/gsp_rm_emulation.c/h: GSP-RM msgq emulation engine - Queue chain discovery (libos args → RMARGS → GSP_ARGUMENTS_CACHED) - Status queue link + GSP_INIT_DONE emission - Command queue polling + RPC dispatch - SET_GUEST_SYSTEM_INFO version negotiation (VGX 41.12) - GET_GSP_STATIC_INFO(65) with 1656-byte GspStaticConfigInfo - GSP_RM_CONTROL(76) sub-command dispatch: - FIFO_GET_DEVICE_INFO_TABLE (0x20801112) - INTERNAL_INTR_GET_KERNEL_TABLE (0x20800a5c) - GPU_GET_CONSTRUCTED_FALCON_INFO (0x208001b0) - INTERNAL_GET_DEVICE_INFO_TABLE (0x20800a40) - kernel/gsp_rm_tu104.h: TU104 hardware tables - 12-entry FIFO engine table (GR0, CE0-4, NVDEC0-1, NVENC0, SEC2, NVJPG, SW) - 8-entry interrupt table (from intr_phys_tu102.c) - 1-entry constructed falcon table (FBFLCN) - 11-entry internal device info table - GspStaticConfigInfo layout (1656 bytes, ABI-verified offsets) - Data from NVIDIA driver material (ext-tree) + hwref/turing/tu104 - tools/rmq/: Userspace RM API client (oracle for ground-truth tables) KNOWN ISSUE: gsp_rm_send crashes (fortify_panic) on multi-element messages when reply data exceeds one 4096-byte queue element. Affects cmd 0x20800a41 (paramsSize=8204). Multi-element splitting is the next fix. --- tools/rmq/wpr2_reset.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 tools/rmq/wpr2_reset.c (limited to 'tools/rmq/wpr2_reset.c') diff --git a/tools/rmq/wpr2_reset.c b/tools/rmq/wpr2_reset.c new file mode 100644 index 0000000..4435843 --- /dev/null +++ b/tools/rmq/wpr2_reset.c @@ -0,0 +1,50 @@ +/* wpr2_reset - clear GPU WPR2 registers via BAR0 MMIO to unstick GSP boot. + * + * When nvidia.ko is unloaded, GSP firmware can remain resident in WPR2 + * (write-protected region 2 in FB). The next RmInitAdapter then fails with + * "unexpected WPR2 already up". FLR does not clear WPR2; only a cold (power) + * reset does. This tool pokes WPR2_ADDR_LO/HI to zero directly through + * /sys/bus/pci/devices//resource0 while no driver is bound. + * + * Usage: sudo ./wpr2_reset [pci.bdf] (default 0000:01:00.0) + */ +#include +#include +#include +#include +#include +#include +#include + +#define NV_PFB_PRI_MMU_WPR2_ADDR_LO 0x1fa824 +#define NV_PFB_PRI_MMU_WPR2_ADDR_HI 0x1fa828 + +int main(int argc, char **argv) +{ + const char *bdf = argc > 1 ? argv[1] : "0000:01:00.0"; + char path[256]; + snprintf(path, sizeof(path), "/sys/bus/pci/devices/%s/resource0", bdf); + + int fd = open(path, O_RDWR | O_SYNC); + if (fd < 0) { perror(path); return 1; } + void *bar = mmap(NULL, 0x200000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); + if (bar == MAP_FAILED) { perror("mmap"); return 1; } + + volatile uint32_t *lo = (volatile uint32_t *)((char *)bar + NV_PFB_PRI_MMU_WPR2_ADDR_LO); + volatile uint32_t *hi = (volatile uint32_t *)((char *)bar + NV_PFB_PRI_MMU_WPR2_ADDR_HI); + + printf("before: WPR2_ADDR_LO=0x%08x WPR2_ADDR_HI=0x%08x\n", *lo, *hi); + *lo = 0; + *hi = 0; + /* read back */ + printf("after : WPR2_ADDR_LO=0x%08x WPR2_ADDR_HI=0x%08x\n", *lo, *hi); + + if (*hi == 0) + printf("WPR2 cleared - driver load should now boot GSP cleanly\n"); + else + printf("write dropped (PLM?) - WPR2 still up\n"); + + munmap(bar, 0x200000); + close(fd); + return *hi ? 1 : 0; +} -- cgit v1.2.3