On 9/18/26 06:09, SRINIVASAN SHANMUGAM wrote: ... >>>> + /* >>>> + * Build an iosys_map for the TMA CPU mapping. On dGPUs the TMA BO >>>> + * may be placed in VRAM and accessed via MMIO (PCI BAR). Check >>>> + * TTM_BO_MAP_IOMEM_MASK to select the correct write accessor. >>>> + */ >>>> + if (cwsr->tma_bo->kmap.bo_kmap_type & TTM_BO_MAP_IOMEM_MASK) >>>> + iosys_map_set_vaddr_iomem(&cwsr->tma_map, >>>> + (void __iomem *)cpu_addr); >>>> + else >>>> + iosys_map_set_vaddr(&cwsr->tma_map, cpu_addr); >>>> + >>> Clear NAK to that hack. Please use ttm_bo_vmap() instead if you need an >>> iosys_map. >> >> Hi Christian, >> >> Thanks. One clarification regarding using |ttm_bo_vmap()| here. >> >> The per-VM TMA BO is unpinned and can be moved/evicted. Currently >> |amdgpu_bo_move_notify()| calls |amdgpu_bo_kunmap()|, so the existing >> |amdgpu_bo_kmap()| mapping is dropped before a move. >> >> If we replace it with |ttm_bo_vmap()| and keep the returned |iosys_map| in >> the trap object, should we also handle unmapping/remapping it across BO >> moves, or would you prefer mapping it only around the TMA accesses? >> > Since the per-VM TMA BO is unpinned and movable, keeping the |ttm_bo_vmap()| > mapping in the trap object would require us to invalidate/remap it whenever > the BO moves. > > To avoid maintaining a long-lived mapping for an evictable BO, I'm thinking > of using |ttm_bo_vmap()| only around the TMA CPU accesses while the BO is > reserved, and calling |ttm_bo_vunmap()| before releasing the reservation. > > This should also avoid leaving a stale |iosys_map| after BO migration. > > Does that sound like the preferred approach?
Good question, I think we should just temporary map the trap handler to patch in the addresses. That happens most likely only once during application startup, so it isn't time critical or anything. Regards, Christian. > > Thanks, > Srini > >
