On 3/24/21 10:58 AM, Daniel Vetter wrote:
On Tue, Mar 23, 2021 at 09:42:18PM +0100, Thomas Hellström (Intel) wrote:
On 3/23/21 8:52 PM, Williams, Dan J wrote:
On Sun, 2021-03-21 at 19:45 +0100, Thomas Hellström (Intel) wrote:
TTM sets up huge page-table-entries both to system- and device memory, and we don't want gup to assume there are always valid backing struct pages for these. For PTEs this is handled by setting the pte_special bit, but for the huge PUDs and PMDs, we have neither pmd_special nor pud_special. Normally, huge TTM entries are identified by looking at vma_is_special_huge(), but fast gup can't do that, so as an alternative define _devmap entries for which there are no backing dev_pagemap as special, update documentation and make huge TTM entries _devmap, after verifying that there is no backing dev_pagemap.
Please do not abuse p{m,u}d_devmap like this. I'm in the process of removing get_devpagemap() from the gup-fast path [1]. Instead there should be space for p{m,u}d_special in the page table entries (at least for x86-64). So the fix is to remove that old assumption that huge pages can never be special.
Hmm, yes with that patch it will obviously not work as intended.
Given that, I think we'll need to disable the TTM huge pages for now until we can sort out and agree on using a page table entry bit.
Yeah :-/
I think going full pud/pmd_mkspecial should then also mesh well with Jason's request to wrap it all up into a vmf_insert_* helper, so at least it would all look rather pretty in the end.
Yes, I agree. Seems like the special (SW1) is available also for huge page table entries on x86 AFAICT, although just not implemented. Otherwise the SW bits appear completely used up.
The PTE size vmf_insert_pfn__xxx functions either insert one of devmap or special. I think the only users of the huge insert functions apart form TTM currently insert devmap so we should probably be able to do the same, and then DRM / TTM wouldn't need to care at all about special or not.
/Thomas
-Daniel