[Intel-gfx] query on gem vma unbinding

[Intel-gfx] query on gem vma unbinding

[Dave Airlie]

I've been trying to work out what path invalidate the vmas for the
following userspace behaviour, seen with iris/X.org but it's a bit of
a maze.

(address are fictional)
userspace allocates bo 1, assigns it a VMA. 0x1000
userspace allocates bo 2, assigns it a VMA  0x2000

Submits work with these addresses pinned

bo 2 is freed in userspace into the userspace cache
userspace allocates bo 3 in a incompatible VMA space gets 2 from
cache, frees VMA 0x2000, allocates VMA 0x20000
userspace alloates bo 4, assign it VMA 0x2000

When I get to the VMA space for BO 4 in the kernel, the VMA node is
not allocated so it's misplaced, but if you try and allocate a node,
the previous node hasn't been unbound, since the NOEVICT flags is set,
ENOSPC should return, but then does the GEM code then use relocations
and place the buffer somwhere else?

I'm just not seeing a path to i915_vma_unbind for 0x2000 vma, or a
path to evicting it.

Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] query on gem vma unbinding

[Chris Wilson]

Quoting Dave Airlie (2020-09-14 07:27:18)
> I've been trying to work out what path invalidate the vmas for the
> following userspace behaviour, seen with iris/X.org but it's a bit of
> a maze.
> 
> (address are fictional)
> userspace allocates bo 1, assigns it a VMA. 0x1000
> userspace allocates bo 2, assigns it a VMA  0x2000
> 
> Submits work with these addresses pinned
> 
> bo 2 is freed in userspace into the userspace cache
> userspace allocates bo 3 in a incompatible VMA space gets 2 from
> cache, frees VMA 0x2000, allocates VMA 0x20000
> userspace alloates bo 4, assign it VMA 0x2000
> 
> When I get to the VMA space for BO 4 in the kernel, the VMA node is
> not allocated so it's misplaced, but if you try and allocate a node,
> the previous node hasn't been unbound, since the NOEVICT flags is set,
> ENOSPC should return, but then does the GEM code then use relocations
> and place the buffer somwhere else?

It takes the slow path, upon vma insert drm_mm_reserve_node() reports
ENOSPC and we then do an evict_for_node, unbind the previous occupants
or report the error back to userspace for trying to use an unevictable
location (which for iris should only be if it specifies the same address
twice in a batch for different objects).
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx