On Tue, Mar 23, 2021 at 05:34:51PM +0100, Thomas Hellström (Intel) wrote:
Isn't the devmap PTE flag arch optional? Does this fall back to notYes, that should work.@@ -210,6 +211,20 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault *vmf,I think we can do this statically:
if ((pfn & (fault_page_size - 1)) != 0)
goto out_fallback;
+ /*
+ * Huge entries must be special, that is marking them as devmap
+ * with no backing device map range. If there is a backing
+ * range, Don't insert a huge entry.
+ * If this check turns out to be too much of a performance hit,
+ * we can instead have drivers indicate whether they may have
+ * backing device map ranges and if not, skip this lookup.
+ */
- if it's system memory we know there's no devmap for it, and we do the
trick to block gup_fast
- if it's iomem, we know gup_fast wont work anyway if don't set PFN_DEV,I think gup_fast will unfortunately mistake a huge iomem page for an
so might as well not do that
ordinary page and try to access a non-existant struct page for it, unless we
do the devmap trick.
And the lookup would then be for the rare case where a driver would have
already registered a dev_pagemap for an iomem area which may also be mapped
through TTM (like the patch from Felix a couple of weeks ago). If a driver
can promise not to do that, then we can safely remove the lookup.
using huge pages on arches that don't support it?
Also, I feel like this code to install "pte_special" huge pages does
not belong in the drm subsystem..
Jason