On 24-08-2026 20:37, Rob Clark wrote: >>> qda_memory_dma.c / qda_memory_dma.h >>> DMA coherent allocation backend. qda_dma_alloc() calls >>> dma_alloc_coherent() on the CB device and encodes the stream ID >>> (SID) in the upper 32 bits of the returned DMA address, following >>> the Qualcomm FastRPC convention for IOMMU address space tagging. >>> qda_dma_free() strips the SID prefix before calling >>> dma_free_coherent(). >>> >>> qda_memory_manager.c >>> Adds process-to-device assignment: each DRM file (process) is >>> assigned one IOMMU context bank device for the lifetime of the >>> session. qda_memory_manager_assign_device() first checks whether >>> the process already has a device (reusing it with a refcount >>> increment), then falls back to claiming an unassigned device. >>> qda_memory_manager_alloc() and qda_memory_manager_free() delegate >>> to the DMA backend after resolving the correct CB device for the >>> calling process. >> Oh, stuff like that is usually a pretty big NO-GO now. >> >> AMD has made the same mistake with KFD and it resulted in a massive chaos. >> >> The DRM file is the driver context your process uses and even if there are >> multiple DRM files for the same PID you should absolute *NOT* share anything >> between them. >> >> The general rule of thumb is to not attach anything to the process using the >> DRM file descriptor. > A couple other things to keep in mind: > > 1. drm device fd can be passed across processes > 2. virtgpu/virglrenderer drm native ctx is a single process that opens > the drm device file N times on behalf of N guest userspace processes. > > All that to say, Christian is right here.. drm_file is your context, > pgtables should be attached to the drm_file (potentially via > drm_gpuvm.. which you perhaps want to use). > > BR, > -R > >> Regards, >> Christian. >>
Hi Christian, Rob, Thank you for highlighting this. I'll rework the CB assignment to be per-drm_file. Each open() will get a CB assigned from the available pool (find-first-available, not find-by-PID). The assigned_pid field and PID-matching logic will be removed entirely. The hardware has a limited number of context banks that serve many sessions (on fastrpc, via the DT "qcom,nsessions" property), so multiple drm_files may end up sharing the same underlying CB due to hardware constraints, but while implementing that also, I'll ensure that the association goes through drm_file->driver_priv, never through a PID scan. I'll also look into drm_gpuvm for the longer-term address space management as Rob suggested. Thanks, Ekansh
