On Wed, Aug 26, 2026 at 07:15:07PM +0530, Ekansh Gupta wrote: > 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'd strongly suggest to implement a simple case and not to implement CB sharing for now. > I'll also look into drm_gpuvm for the longer-term address space > management as Rob suggested. Nice. I think I've beeng trying point it out, but maybe not very explicit. -- With best wishes Dmitry
