Am 08.02.24 um 01:36 schrieb Dave Airlie:
Just cc'ing some folks. I've also added another question.
On Wed, 7 Feb 2024 at 21:08, Maíra Canal <mcanal@xxxxxxxxxx> wrote:
Adding another point to this discussion, would it make sense to somehow
create a generic structure that all drivers, including shmem drivers,
could use it?
Best Regards,
- Maíra
On 2/7/24 03:56, Dave Airlie wrote:
I'm just looking over the userptr handling in both drivers, and of
course they've chosen different ways to represent things. Again this
is a divergence that is just going to get more annoying over time and
eventually I'd like to make hmm/userptr driver independent as much as
possible, so we get consistent semantics in userspace.
AFAICS the main difference is that amdgpu builds the userptr handling
inside a GEM object in the kernel, whereas xe doesn't bother creating
a holding object and just handles things directly in the VM binding
code.
Is this just different thinking at different times here?
like since we have VM BIND in xe, it made sense not to bother creating
a gem object for userptrs?
or is there some other advantages to going one way or the other?
So the current AMD code uses hmm to do userptr work, but xe doesn't
again, why isn't xe using hmm here, I thought I remembered scenarios
where plain mmu_notifiers weren't sufficient.
Well amdgpu is using hmm_range_fault because that was made mandatory for
the userptr handling.
And yes pure mmu_notifiers are not sufficient, you need the sequence
number + retry mechanism hmm_range_fault provides.
Otherwise you open up security holes you can push an elephant through.
Regards,
Christian.
Dave.
