locking&resource refcounting for ttm_bo_kmap/dma_buf_vmap

[Thomas Zimmermann]

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.

> - 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?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20191121/2134db6d/attachment-0001.sig>