On Mon, 22 Aug 2022 at 17:05, Dave Airlie <airlied@xxxxxxxxx> 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.
