diff options
| author | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-25 07:23:52 -0400 |
|---|---|---|
| committer | Arthur Hanson Rasmusson <arthur@vgpu.io> | 2026-10-25 07:23:52 -0400 |
| commit | e3c1cdc5ee049797fe40ae648d2a936c7384d517 (patch) | |
| tree | d5e894848e9db33000273f913b672838e14356be /wiki/BAR-Emulation-Specification.md | |
| parent | 8d8567c91f282078251d7bd2fc301e7fd438ec36 (diff) | |
| download | open-iov-e3c1cdc5ee049797fe40ae648d2a936c7384d517.tar.gz open-iov-e3c1cdc5ee049797fe40ae648d2a936c7384d517.zip | |
vgsp-rm r682: register NV01_EVENT_KERNEL_CALLBACK (0x78) and NV01_EVENT_KERNEL_CALLBACK_EX (0x7E) events alongside OS_EVENT (0x79)
The driver's modern nvkms/Vulkan path allocates its per-channel
completion events with class 0x7E (nvos.h NV01_EVENT_KERNEL_CALLBACK_EX;
observed live as GSP_RM_ALLOC class=0x7e paramsSize=24 hParent=<subdevice>
hObject=0xcaf00003 from the second RM client while its main thread sat in
the vkCreateDevice wait loop, whose readiness word lives in a
/dev/nvidiactl notification page that only an event completion can
signal). The event registration scanned the params for hClass 0x79 only,
so 0x7E allocations were never registered and their completion wake-ups
(post_channel_event/post_all_events) could never reach them. Accept all
three event classes; the NV0005_ALLOC_PARAMETERS layout is the same
{hParentClient, hSrcResource, hClass, notifyIndex, data}.
Diffstat (limited to 'wiki/BAR-Emulation-Specification.md')
0 files changed, 0 insertions, 0 deletions
