From fffae7b19383373a95032645c583ccf76add23df Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Tue, 27 Oct 2026 05:29:10 -0400 Subject: vgsp: X/GL wall broken - PROMOTE_CTX registry, small trusted-NOP acceptance, push-scoped release deferral The X server now starts on the emulated vGPU and GLX runs on the real NVIDIA driver: Xorg :0 passes its DMA sanity push and ScreenInit, and DISPLAY=:0 glxinfo reports 'OpenGL 4.6.0 NVIDIA 570.144' with direct rendering; GZDOOM 4.14.2 launches and renders. Before this, every X start died at 'NVIDIA(GPU-0): Failed to initialize DMA' (the __nvPushTestPushBuffer 10 s GP_GET wait) and no nvidia-push kernel buffer could be resolved. What each piece fixes (all observed live on the r817->r827 cycles): - sema: register the driver's PROMOTE_CTX context-buffer statements as a VA->PA registry, consulted as the LAST resort after every walk. A promoted (va, pa) pair is a VA-space booking, not a mapping: its span can swallow other buffers' VAs (the ctx MAIN booking covered the channel GPFIFO VA and range arithmetic answered the entry validation with MAIN.pa+offset, a zero page - the latch never fired, r823), and even its base page can host a separately mapped buffer (the PATCH booking's base VA hosts nvidia-push's 4 KB progress semaphore; the release landed in the booking's page while the driver's own polled page stayed zero, r826). The walks describe the real mappings and must answer first. - sema: an all-zero GR push of <= 16 bytes resolved by the trusted chain (src=4) is accepted as the driver's NOP sanity push (NVA16F_DMA_NOP is a single zero dword; real launches are hundreds of bytes). The r496e acceptance required a content-scanned ring, which the X/GL channel is not. - sema: the wave-1.5 release deferral is push-scoped. A release whose push owns no captured forward candidate has nothing to wait for; it applies inline (the progress-tracker semaphore release used to be recorded and dropped at every pass reset while an unrelated lingering candidate armed the global defer). - sema: the m164 no-capture hold no longer arms for the accepted zero NOP - it held the NOP entry for its 6 s window 'forcing capture' of a launch that cannot exist. - sema: once the ring resolves, the USERD latch scan may retry past its 8-scan cap (the client's VAS directory registration lost the race against the 10 s DMA window when a rebuild stretched the pass cadence, r820). - sema: dbg-gated USERD-scan decision witnesses (rejection reason, sweep summary, per-call state), GR-only and budgeted. Known next issue (not this change): sustained X/GL rendering traffic wedges the guest RC watchdog ('NVRM: krcWatchdog_IMPL: GPU is probably locked') after minutes of GZDOOM/GLX activity; the FIFO service itself keeps consuming. --- kernel/gsp_rm_emulation.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'kernel/gsp_rm_emulation.c') diff --git a/kernel/gsp_rm_emulation.c b/kernel/gsp_rm_emulation.c index 03f861e..d6412c3 100644 --- a/kernel/gsp_rm_emulation.c +++ b/kernel/gsp_rm_emulation.c @@ -4267,6 +4267,18 @@ static void gsp_rm_handle_rm_control(struct gsp_emu_context *ctx, "vgsp-rm: promote[%u] bufferId=%u bInitialize=%u bNonmapped=%u physAttr=0x%x pa=0x%llx va=0x%llx size=0x%llx", i, bid, e[30], e[31], attr, pa, eva, esz); + /* + * r820: register the driver's own statement + * of this kernel buffer's backing (r817 + * Xorg GL init: the page-table walk answered + * a stale zero page for the pushbuffer VA + * while this entry named the real one; a + * userspace pin scanner can never cover + * kernel-owned buffers). See + * gsp_sema_service_promote_add(). + */ + gsp_sema_service_promote_add(eva, pa, esz, + attr, bid); } } out_status = 0; -- cgit v1.2.3