I found that this was needed for the GT1 hardware unit to come up with GuC firmware enabled on meteorlake

In D59436#1363212, @ashafer wrote:

I found that this was needed for the GT1 hardware unit to come up with GuC firmware enabled on meteorlake

Can you tell us in which version and possibly where the code (argument) comes from?
I am trying to understand how this is supposed to work but cannot find many PAGE_* definitions (well PAGE_KERNEL[_IO]) in LinuxKPI.

It gets called from drm-kmod, in the case of i915 this seems to usually originate from i915_gem_object_map_page()->vmap() when the caller uses I915_MAP_WC. There's quite a few paths that make it to using this function, some of them will set I915_MAP_(WB|WC) such as from intel_guc_init->intel_uc_fw_init()

In D59436#1363989, @ashafer wrote:

It gets called from drm-kmod, in the case of i915 this seems to usually originate from i915_gem_object_map_page()->vmap() when the caller uses I915_MAP_WC. There's quite a few paths that make it to using this function, some of them will set I915_MAP_(WB|WC) such as from intel_guc_init->intel_uc_fw_init()

Let's stay with this example: I915_MAP_WC is an internal value from an enum; how does that then get mapped to PAGE_KERNEL* values (which we do not define). I wonder does it get mapped straight to FreeBSD internal VM_ values?

306     case I915_MAP_WC:
307         pgprot = pgprot_writecombine(PAGE_KERNEL_IO);
308         break;

Here's the bit from i915_gem_object_map_page. We calculate page protections from PAGE_KERNEL_IO and linuxkpi's pgprot_writecombine really just turns that into VM_*. Then i915 passes pgprot into vmap. We do also define PAGE_KERNEL in vmalloc.h and PAGE_KERNEL_IO in page.h

In D59436#1364598, @ashafer wrote:

306     case I915_MAP_WC:
307         pgprot = pgprot_writecombine(PAGE_KERNEL_IO);
308         break;

Here's the bit from i915_gem_object_map_page. We calculate page protections from PAGE_KERNEL_IO and linuxkpi's pgprot_writecombine really just turns that into VM_*. Then i915 passes pgprot into vmap. We do also define PAGE_KERNEL in vmalloc.h and PAGE_KERNEL_IO in page.h

Yes, that's what I meant in the first comment; We have PAGE_KERNEL[_IO] but none of all the others.

Neither is used beyond the define.

% grep -r PAGE_KERNEL sys/compat/linuxkpi/
sys/compat/linuxkpi/common/include/linux/vmalloc.h:#define      PAGE_KERNEL     0x0000
sys/compat/linuxkpi/common/include/linux/page.h:#define PAGE_KERNEL_IO  0x0000
%

And pgprot2cachemode() then maps these both to VM_MEMATTR_DEFAULT.

But in your sample I see that pgprot_writecombine(); and that and others map things to native VM_MEMATTR_ values in LinuxKPI directly.

Thanks a lot for the explanations and code samples! Really helped to understand how this is supposed to come together.

I take it, this code fixes the problem reported here: https://github.com/freebsd/drm-kmod/pull/496 ? If it does, thank you very much for writing it! I'll test this code later.

Not 100% confident, but that drm-kmod issue seems similar enough I think there's a decent chance this solves it. More testing would definitely be helpful

I tested your patch with vanilla drm-kmod today, and it didn't solve the problem that my github PR's code had solved for me. But thanks anyway for writing it.