summaryrefslogtreecommitdiffstats
path: root/kernel/include
diff options
context:
space:
mode:
authorArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-04 16:19:31 -0400
committerArthur Hanson Rasmusson <arthur@vgpu.io>2026-10-04 16:19:31 -0400
commitaa3520f252182aaf64ea0b8856a3ac5e4466ce0e (patch)
treef5382da924162e6b0705c2eeff60361cf3911cda /kernel/include
parent5d305e94d028f14edffa042f006770494fda1d86 (diff)
downloadopen-iov-aa3520f252182aaf64ea0b8856a3ac5e4466ce0e.tar.gz
open-iov-aa3520f252182aaf64ea0b8856a3ac5e4466ce0e.zip
vgsp: end-to-end CUDA acceptance in the guest
The no-claim emulation path now runs a stock CUDA program end to end: device properties, cudaMalloc, a GPU-authored string kernel read back byte-for-byte, two 4 MB host-to-device copies, a 1 M-element vectorAdd executed on the physical GPU through the host bridge, and the device-to-host copy-back verified element by element. Three consecutive supervised cycles report MAIL + VADD bad=0 checksum=392344090.500000 + STATUS OK with identical input/output hashes. Two data-path correctness fixes make the transfers sound: - Once-only op execution per GPFIFO entry. The pump replays recently consumed ring entries when translation batches are injected so missed releases can land; re-executing a CE copy is not idempotent because its source is a client staging buffer that may have been refilled. Slots now record their raw entry words and a replayed entry matching that identity suppresses operations while still processing releases. - Per-page translation of virtual operands. svc_copy resolved only the first page of a VA range and walked the PA linearly; client staging ranges are frequently split (observed 195 + 61 pages), so the tail of alternating chunks was read from unrelated memory. Multi-page copies now re-resolve each 4 KB page through the trusted resolver. Also carries the earlier uncommitted emulation fixes that got the client to the launch (QMD address-window gate, counter registration persistence, 512 MiB emulated FB, bridge slot hygiene) and bounded diagnostics (sema-bigop, sema-bigcopy, bridge-in/out hashes, daemon INCHECK/OUTCHECK/dumps).
Diffstat (limited to 'kernel/include')
-rw-r--r--kernel/include/nvidia-vgpu-vfio.h20
1 files changed, 19 insertions, 1 deletions
diff --git a/kernel/include/nvidia-vgpu-vfio.h b/kernel/include/nvidia-vgpu-vfio.h
index 1c2f67b..ccd7262 100644
--- a/kernel/include/nvidia-vgpu-vfio.h
+++ b/kernel/include/nvidia-vgpu-vfio.h
@@ -25,7 +25,18 @@
#define NV_VGPU_MAX_IRQS NVIDIA_VGPU_MAX_IRQS
#define NV_VGPU_BAR0_SIZE (16 * 1024 * 1024)
-#define NV_VGPU_BAR1_SIZE (256 * 1024 * 1024)
+/*
+ * BAR1 (VRAM aperture) and the emulated framebuffer size. These two move
+ * together: the guest derives its BAR1 size from fbLength
+ * (kbusInitBarsSize_VF: pciBarSizes[1] = pGpu->fbLength), and its vidmem
+ * address space is [0, fbLength). The shadow backing bars[1].vaddr is
+ * NV_VGPU_BAR1_SIZE, so any guest vidmem PA the emulation translates must
+ * stay inside it. 512 MiB gives UVM enough headroom after its own
+ * reservations to satisfy the acceptance program's 3x4 MiB vadd buffers
+ * (at 256 MiB the guest reported only ~5 MiB free).
+ */
+#define NV_VGPU_BAR1_SIZE (512 * 1024 * 1024)
+#define NV_VGPU_EMUL_FB_SIZE (512ULL * 1024 * 1024)
#define NV_VGPU_BAR2_SIZE (32 * 1024 * 1024)
#define NV_VGPU_BAR3_SIZE (32 * 1024 * 1024)
@@ -56,6 +67,13 @@ struct nv_vgpu_bar {
void *vaddr;
bool mapped;
bool trapped;
+ /*
+ * True when vaddr is a host-RAM shadow (vzalloc) owned by this module
+ * instead of an ioremap'd physical BAR. Guest mappings must then remap
+ * the shadow's own pages; a real BAR must never be exposed to the
+ * guest outside the supervised physical claim.
+ */
+ bool emulated;
struct mutex lock;
};