vm binding interfaces and parallel with mmap

[Dave Airlie]

On Mon, 22 Aug 2022 at 17:05, Dave Airlie <airlied at gmail.com> wrote:
>
> Hey,
>
> I've just been looking at the vm bind type interfaces and wanted to at
> least document how we think the unmapping API should work. I know I've
> talked on irc before about this, but wanted to solidify things a bit
> more around what is required vs what is a nice to have.
>
> My main concerns/thoughts are around the unbind interfaces and how
> close to munmap they should be.
>
> I think the mapping operation is mostly consistent
> MAP(bo handle, offset into bo, range, VM offset, VM flags)
> which puts the range inside to bo at the offset in the current VM
> (maybe take an optional vm_id).
>
> now the simplest unmap I can see if one that parallel munmap
> UNMAP(vmaddr, range);
>
> But it begs the question on then how much the kernel needs to deal
> with here, if we support random vmaddr,range then we really need to be
> able to do everything munmap does for CPU VMA, which means splitting
> ranges, joining ranges etc.
>
> like
> MAP(1, 0, 0x8000, 0xc0000)
> UNMAP(0xc1000, 0x1000)
> should that be possible?
>
> Do we have any API usage (across Vulkan/CL/CUDA/ROCm etc) that
> requires this sort of control, or should we be fine with only
> unmapping objects exactly like how they were mapped in the first
> place, and not have any splitting/joining?

I suppose it also asks the question around paralleling

fd = open()
ptr = mmap(fd,)
close(fd)
the mapping is still valid.

I suppose our equiv is
handle = bo_alloc()
gpu_addr = vm_bind(handle,)
gem_close(handle)
is the gpu_addr still valid does the VM hold a reference on the kernel
bo internally.

Dave.
>
> Dave.