On Thu, Nov 21, 2019 at 8:59 AM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > > Hi > > Am 20.11.19 um 12:47 schrieb Daniel Vetter: > > Hi all, > > > > I've been looking at dma_buf_v(un)map, with a goal to standardize > > locking for at least dynamic dma-buf exporters/importers, most likely > > by requiring dma_resv_lock. And I got questions around how this is > > supposed to work, since a big chunk of drivers seem to entirely lack > > locking around ttm_bo_kmap. Two big ones: > > > > - ttm_bo_kmap looks at bo->mem to figure out what/where to kmap to get > > at that buffer. bo->mem is supposed to be protected with > > dma_resv_lock, but at least amgpu/nouveau/radeon/qxl don't grab that > > in their prime vmap function. > > > > - between the vmap and vunmap something needs to make sure the backing > > storage doesn't move around. I didn't find that either anywhere, > > ttm_bo_kmap simply seems to set up the mapping, leaving locking and > > refcounting to callers. > > You have to pin and unpin storage before and after mapping. Yeah, but you = the exporter, not the importer. I.e. the vmap callback should pin and vunmap should unpin. It's not a huge deal since currently all users of dma_buf_vmap I've found do a dma_buf_attach (even if they never use the attachment directly), and with drm prime helpers the attach results in a pin. Or that's at least the story I told myself to believe this is all not a totally fireworks show right now :-) > > - vram helpers have at least locking, but I'm still missing the > > refcounting. vmwgfx doesn't bother with vmap. > > There's a ref counter for pinning [1] and there's a counter for mapping. > [2] Are you looking for something else? vram helpers actually looked pretty good in this regard. If you look at other callers of ttm_bo_kmap, they're a lot more fast&loose here. -Daniel > > Best regards > Thomas > > [1] > https://cgit.freedesktop.org/drm/drm-tip/tree/include/drm/drm_gem_vram_helper.h?id=8d3996ceedcd5c64f5a354e9dcc64db4a1f72dd6#n69 > [2] > https://cgit.freedesktop.org/drm/drm-tip/tree/include/drm/drm_gem_vram_helper.h?id=8d3996ceedcd5c64f5a354e9dcc64db4a1f72dd6#n63 > > > > > What am I missing? > > > > Thanks, Daniel > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
