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. --- kernel/bar_emulation.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) (limited to 'kernel/bar_emulation.c') diff --git a/kernel/bar_emulation.c b/kernel/bar_emulation.c index e120b3c..eaa006c 100644 --- a/kernel/bar_emulation.c +++ b/kernel/bar_emulation.c @@ -252,6 +252,33 @@ int nv_vgpu_bar_emul_init(struct nv_vgpu_device *vgpu) *(u32 *)((u8 *)ctx->bar0_shadow + 0x118234) = 0x000000ff; *(u32 *)((u8 *)ctx->bar0_shadow + 0x110100) = 0x00000010; + /* + * More post-GFW-boot state the driver validates before/while booting + * GSP-RM: + * 0x1100f4 GSP falcon HWCFG2 bit10 RISCV = ENABLE. Checked by + * kflcnIsRiscvCpuEnabled in kgspPrepareForBootstrap; + * without it probe dies with "RISC-V core is not enabled". + * 0x009430 NV_PTIMER_TIME_PRIV_LEVEL_MASK bit4 + * WRITE_PROTECTION_LEVEL0 = ENABLE. FWSEC lowers PLMs + * after GFW boot; driver asserts "Write to PTIMER + * attempted even though Level 0 PLM is disabled" when + * setting the GPU clock otherwise. + */ + *(u32 *)((u8 *)ctx->bar0_shadow + 0x1100f4) = 0x00000400; + *(u32 *)((u8 *)ctx->bar0_shadow + 0x009430) = 0x00000010; + + /* + * 0x100ce0 NV_PFB_PRI_MMU_LOCAL_MEMORY_RANGE - usable FB size. + * Encoded as fbSize = LOWER_MAG << (LOWER_SCALE + 20). Set to + * 256MB (matches our BAR1): mag=1, scale=8 -> 1 << 28. On real + * hardware VBIOS devinit programs this after GFW boot; the guest + * driver's kgspPopulateWprMeta reads it via kmemsysGetUsableFbSize + * and uses it to compute the FRTS offset (fbSize - reservedFromEnd). + * With it 0, the FRTS offset underflows and FWSEC verification + * fails with "WPR2 initialized at an unexpected location". + */ + *(u32 *)((u8 *)ctx->bar0_shadow + 0x100ce0) = 0x00000018; + /* * Serve a valid VBIOS at the PROM window (BAR0+0x300000). * -- cgit v1.2.3