diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-09-23 14:03:27 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-09-23 14:03:27 -0400 |
| commit | 2a59dcb768541b759ada9cd6f24986e2c234bd37 (patch) | |
| tree | 862bedd8078b64871e34ece655d627dc7ba3dccd /kernel/gsp_sema_service.h | |
| parent | fade84f8b5b781d29daad40699d07928dedea550 (diff) | |
| download | open-iov-2a59dcb768541b759ada9cd6f24986e2c234bd37.tar.gz open-iov-2a59dcb768541b759ada9cd6f24986e2c234bd37.zip | |
kernel: track channels and execute host-class pushed work
The guest's CUDA stack was stuck inside context creation because the work it
submits is never executed by the emulated GPU. Two forms of pushed work were
missing, and the completion path had grown far too slow to be useful:
- Channel tracking: on a channel allocation parse the GPFIFO GPU VA and entry
count, the USERD address/aperture and the instance block, hand them to the
progress service and drop them again when the channel is freed.
- Host-class (C46F) semaphore releases: pushes on a compute channel signal
progress with a five-dword method run (SEM_ADDR_LO/HI, PAYLOAD_LO/HI,
EXECUTE) rather than the copy-engine group the service already understood,
so those releases were never applied. Decode both forms.
- Emulated vidmem: channel blocks (USERD/instance) and some client semaphores
live in the emulated frame buffer, whose VAs are a window over the BAR1
backing rather than guest RAM; access them through the right aperture.
- Latency: the service's full-RAM sweep took seconds per pass, so guests'
progress waits took whole seconds and the driver tore its own setup back
down in the meantime. Sweep guest RAM in bounded, chunked windows on every
pass, remember the pages pushes are actually found in and revisit those
first, and keep the VA->PA map complete (dedup, sort, binary search) so
semaphores resolve reliably.
Also add a vidmem poke parameter for bringing up and debugging emulated
frame-buffer state.
Diffstat (limited to 'kernel/gsp_sema_service.h')
| -rw-r--r-- | kernel/gsp_sema_service.h | 23 |
1 files changed, 23 insertions, 0 deletions
diff --git a/kernel/gsp_sema_service.h b/kernel/gsp_sema_service.h index f6ec3fc..16a045f 100644 --- a/kernel/gsp_sema_service.h +++ b/kernel/gsp_sema_service.h @@ -10,6 +10,29 @@ * See gsp_sema_service.c for the full description. */ +/* + * A guest channel, registered when the driver allocates it. The service uses + * the channel's GPFIFO + USERD to notice submissions as they happen (instead + * of discovering the pushed work by scanning guest RAM) and to run the pushed + * work promptly. + * + * All addresses are guest-physical except gpfifo_va, which is the GPU VA of + * the channel's GPFIFO ring (translated through the discovered VA->PA map). + */ +struct sema_channel_desc { + u32 h_object; + u32 engine_type; + u64 gpfifo_va; + u32 gpfifo_entries; + u64 userd_pa; /* NvA06FControl: GPGet @0x88, GPPut @0x8c */ + u32 userd_as; /* NV_ADDR_SYSMEM(1) / NV_ADDR_FBMEM(2) */ + u64 instance_pa; + u64 notifier_pa; +}; + +void gsp_sema_service_channel_add(const struct sema_channel_desc *desc); +void gsp_sema_service_channel_del(u32 h_object); + int gsp_sema_service_start(void); void gsp_sema_service_stop(void); int gsp_sema_service_probe(u64 gpu_va, u32 count); |
