On 3/25/21 1:09 PM, Christian König wrote:
Am 25.03.21 um 13:01 schrieb Jason Gunthorpe:
On Thu, Mar 25, 2021 at 12:53:15PM +0100, Thomas Hellström (Intel)
wrote:
Nope. The point here was that in this case, to make sure mmap uses the
correct VA to give us a reasonable chance of alignement, the driver
might
need to be aware of and do trickery with the huge page-table-entry
sizes
anyway, although I think in most cases a standard helper for this
can be
supplied.
Of course the driver needs some way to influence the VA mmap uses,
gernally it should align to the natural page size of the device
Well a mmap() needs to be aligned to the page size of the CPU, but not
necessarily to the one of the device.
So I'm pretty sure the device driver should not be involved in any way
the choosing of the VA for the CPU mapping.
Christian.
We've had this discussion before and at that time I managed to convince
you by pointing to the shmem helper for this, shmem_get_umapped_area().
Basically there are two ways to do this. Either use a standard helper
similar to shmem's, and then the driver needs to align physical (device)
huge page boundaries to address space offset huge page boundaries. If
you don't do that you can just as well use a custom function that
adjusts for you not doing that (drm_get_unmapped_area()). Both require
driver knowledge of the size of huge pages.
Without a function to adjust, mmap will use it's default (16 byte?)
alignment and chance of alignment becomes very small.
/Thomas
Jason
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
