Userspace transport shim for ANV: sync_file emulation, mapping by ioctl, PCI identity #6

Notes from reading VedCloud's port, which uses NullMoth's transport (PolyForm NC; design reference only, XeGfx is BSD-2):

• Sandboxed apps cannot open /dev/dri. Their libdrm falls back to an IOKit user client on the accelerator (drmNmxOpen / drmNmxIoctl, type 'NMXD'), hands the process a stand-in fd and routes every Mesa intel_ioctl through it. WindowServer and most Metal clients are sandboxed, so our shim needs the same split.
• Mapping by ioctl has to pin. A mapping that cannot be revoked must hold the buffer's pages for its whole lifetime; i915's CPU mmap path did not, so pages could be reclaimed under a live mapping. They also refuse the legacy GTT mmap type and report GTT mmap version 4 (ROADMAP Phase 7).
• sync_file: unclear how ANV's i915_gem_supports_dma_buf_sync_file probe passes on their machine, since their overrides say a kext cannot create the fd. Asked them: see the VedCloud issue linked below.

Question to VedCloud: VedCloud/Meteor-Lake-Xe-LPG-Metal-Graphics#1

Mapping is in 0.0.11 (9a024bf), not run on hardware yet. 'N' 0x40 takes the fake offset from DRM_IOCTL_I915_GEM_MMAP_OFFSET, pins the object's pages and maps them into the caller with IOMemoryDescriptor; 'N' 0x41 unmaps. The struct layout and numbers match NullMoth's Darwin libdrm patch, so libdrm and Mesa need no change for it. WB, WC and UC work, GTT is refused. Closing the node drops its mappings, which mmap(2) would not do. tools/xgprobe.c exercises it end to end. Still open here: sync_file and dma-buf fds for ANV, and an IOKit route for sandboxed clients.

XeGfx 0.0.12 (def47c7, NvGfx xe 38d66a2) adds what Mesa ANV needs before it will start. None of it has run on hardware yet.

• Fences without file descriptors. A kext can't create fds, so libdrm on Darwin now hands out stand-in dma-buf and sync_file descriptors (patches/libdrm-xegfx.patch). The kernel half is two node ioctls that move a buffer's implicit fences to and from a syncobj, with the same rules as Linux's dma-buf sync_file export and import.
• DRM_IOCTL_GET_PCIINFO. libdrm uses it on the BSDs and Darwin to list devices. drm-kmod declares it but never implemented it.
• Mesa (patches/mesa-xegfx.patch): ANV's ioctls and buffer mappings now go through libdrm. The drm-shim chip matrix still passes all 28 simulated chips.

The next boot (N-222, Hybrid mode, panel on the iGPU) runs stages 1 to 6, then xgprobe, drmlist and an ANV device plus compute pipeline on the real node.

VedCloud confirmed how their Meteor Lake port passes ANV's sync_file probe: the kext makes no descriptors; their libdrm bridge intercepts the PRIME and sync_file calls and hands ANV a fake descriptor index it tracks in userspace and maps onto the timeline (VedCloud/Meteor-Lake-Xe-LPG-Metal-Graphics#1 (comment)). That is the same route as 0.0.12 (stand-in fds from libdrm on Darwin, two node ioctls moving implicit fences to and from a syncobj), and theirs runs on hardware. Credit to VedCloud for confirming the design; noted in the README too.

Related: zep245/IrisXe-macos-driver (i915 plus Mesa ANV on Tiger Lake, Sequoia) found that sandboxed apps see no Vulkan device because the sandbox refuses opendir(/dev/dri). They answer it with a hook in the plugin (nvmtl_drmbridge.h) and a shader cache the sandbox can write to. Same problem WindowServer hit for us; a note for the transport shim.

https://github.com/zep245/IrisXe-macos-driver (PolyForm Noncommercial, ideas only)

All three parts are in and have run on hardware: mapping by ioctl in 0.0.11 (9a024bf), stand-in dma-buf and sync_file fds plus DRM_IOCTL_GET_PCIINFO in 0.0.12 (def47c7), and the IOKit route for sandboxed clients such as WindowServer in 0.0.28. drmGetDevices2 lists the GPU on N-233 and ANV creates a Vulkan 1.4 device on N-234 (README). Closing; the Intel desktop work that builds on it is in NvGfx #12.