On 2023-08-09 17:53, Boris Brezillon wrote:
[...]
+/**
+ * struct drm_panthor_vm_create - Arguments passed to DRM_PANTHOR_IOCTL_VM_CREATE
+ */
+struct drm_panthor_vm_create {
+ /** @flags: VM flags, MBZ. */
+ __u32 flags;
+
+ /** @id: Returned VM ID. */
+ __u32 id;
+
+ /**
+ * @kernel_va_range: Size of the VA space reserved for kernel objects.
+ *
+ * If kernel_va_range is zero, we pick half of the VA space for kernel objects.
+ *
+ * Kernel VA space is always placed at the top of the supported VA range.
+ */
+ __u64 kernel_va_range;
Off the back of the "IOVA as unsigned long" concern, Boris and I
reasoned through the 64-bit vs. 32-bit vs. compat cases on IRC, and it
seems like this kernel_va_range argument is a source of much of the pain.
Rather than have userspace specify a quantity which it shouldn't care
about and depend on assumptions of kernel behaviour to infer the
quantity which *is* relevant (i.e. how large the usable range of the VM
will actually be), I think it would be considerably more logical for
userspace to simply request the size of usable VM it actually wants.
Then it would be straightforward and consistent to define the default
value in terms of the minimum of half the GPU VA size or TASK_SIZE (the
latter being the largest *meaningful* value in all 3 cases), and it's
still easy enough for the kernel to deduce for itself whether there's a
reasonable amount of space left between the requested limit and
ULONG_MAX for it to use. 32-bit kernels should then get at least 1GB to
play with, for compat the kernel BOs can get well out of the way into
the >32-bit range, and it's only really 64-bit where userspace is liable
to see "kernel" VA space impinging on usable process VAs. Even then
we're not sure that's a significant concern beyond OpenCL SVM.
Thanks,
Robin.
