linuxkpi: lkpi_vmf_insert_special_pte_locked()

[kib]

Then the following is needed for drm-kmod:

diff --git a/drivers/gpu/drm/i915/i915_mm.c b/drivers/gpu/drm/i915/i915_mm.c
index d1867ddd73..20406fba3e 100644
--- a/drivers/gpu/drm/i915/i915_mm.c
+++ b/drivers/gpu/drm/i915/i915_mm.c
@@ -126,7 +126,7 @@ static int remap_pfn(pte_t *pte, unsigned long addr, void *data)
        set_pte_at(r->mm, addr, pte, pte_mkspecial(pfn_pte(r->pfn, r->prot)));
 #elif defined(__FreeBSD__)
        vm_fault_t ret;
-       ret = lkpi_vmf_insert_pfn_prot_locked(r->vma, addr, r->pfn, r->prot);
+       ret = lkpi_vmf_insert_special_pte_locked(r->vma, addr, r->pfn, r->prot);
        if ((ret & VM_FAULT_OOM) != 0)
                return -ENOMEM;
        if ((ret & VM_FAULT_ERROR) != 0)

[kib]

This is just a prototype, I only compiled the linuxkpi bits

[markj]

I will look at this soon, I just need to resurrect a laptop so that I can easily test i915 changes without taking down my main workstation.

[bz]

So let me ask: is this related to the "fictitious pages" mentioned in D58320? If so, how is the LinuxKPI part to be written/work in the future world order with a real 'struct page'?

[kib]

In D59883#1375406, @bz wrote:

So let me ask: is this related to the "fictitious pages" mentioned in D58320? If so, how is the LinuxKPI part to be written/work in the future world order with a real 'struct page'?

In some sense, yes, it is related. So far I do not know how that proposal about 'real struct page' would work at all. But I do not think that this change (in whatever form after debugging and reviewing it) would have any additional effect on the 'real struct page'.