| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
wakes poll() waiters
The emulated GSP only signalled the MSI-X eventfd when it queued a status
record. The guest's primary ISR (nvidia_isr) decides pending from the
CPU_INTR leaf registers, which we never set for the GSP stall vector, so it
returned IRQ_NONE: IRQ 33 counted thousands of interrupts while the nvidia
event thread sat idle and a client blocked in poll() on /dev/nvidia0 (a GLX
swap) waited forever even though the event was already in the status queue.
Mirror what a real GSP-RM does when it queues an event:
- program RISC-V IRQMASK/IRQDEST for SWGEN0 (read-only to the guest; the
GSP firmware owns them),
- set SWGEN0 in the falcon IRQSTAT,
- latch GSP stall vector 155 in the CPU interrupt tree (LEAF[4] bit 27,
UVM_SHARED subtree 2 -> TOP[0] bit 2),
- signal MSI-X.
Raise it only for POST_EVENT records (replies are polled by the client).
Verified on r1680: the guest now writes IRQSCLR SWGEN0, kgspService_TU102
drains events, and glxgears renders (was a hard hang).
|
|
|
Open-IOV virtualizes NVIDIA GPUs so that unmodified guest drivers run with
real GPU functionality - CUDA first, 3D and video to follow - on unmodified
hosts, without a proprietary vGPU license and without patching any driver,
firmware or hypervisor.
Core principle: emulate the interface, pass through the work.
kernel/ open-iov-vfio.ko - host VFIO mdev driver: virtual GPU device
(PCI config space, BAR shadows, MSI-X), GSP boot emulation,
GSP-RM message-queue/RPC emulation, memory model (GPU-VA to
guest-PA discovery) and the semaphore-completion service that
advances guest UVM progress.
userspace/ libiov.so management API and examples.
tools/ guest diagnostics, firmware analysis wrappers, RM probes.
scripts/ stack manager, VM harness, build/load/test automation.
config/ hardware/version profiles (the portability surface).
docs/ documentation tree - start at docs/README.md.
wiki/ long-form firmware and protocol deep dives.
Status: initialization works end to end for a stock 570.144 Linux guest on
Turing (TU104): driver probe, nvidia-smi, the full GSP-RM control battery,
object creation and the early CUDA/UVM start-up path. GPU work forwarding -
the step that makes CUDA kernels execute on real hardware - is the active
work item; see docs/04-implementation/01-known-knowns-and-unknowns.md.
License: BSD-3-Clause for the project; GPL-2.0 for kernel modules that link
GPL-only kernel interfaces. See LICENSE and docs/09-reference/legal-and-licensing.md.
|
