Is the prot argument about protection, or the cache attributes? I assume the later, and my further response depends on it.

I suggest to not even try to add pmap_qmapdev_attr().
It should be enough to use pmap_qenter().

The problem with the code in D54224 is that it misses ensuring that all mappings have consistent caching mode. This is required e.g. by IA32 (and I am sure by all other arches where FreeBSD runs). The following snippet should be not too far from the working code

bool
f(vm_offset_t va, vm_paddr_r pa, vm_memattr_t mattr)
{
	vm_page_t m;

	m = PHYS_TO_VM_PAGE(pa);
	if (m == NULL)
		return (false);
	pmap_page_set_memattr(m, mattr);
	pmap_qenter(va, &m, 1);
	return (true);
}

And then, if the pmap layer is informed about the desired mapping caching, just pmap_qenter() works.

Hopefully this panic() call would go away in the next iteration.

Later. LinuxKPI does not use protection bits only cache ones.

I am not sure that pmap_qenter() can be used here. Linux has 2 functions:

1. vmap() which is used to map real memory and implemented with pmap_qenter() in LKPI
2. vmap_pfn() which is used to map device memory like PCI BARs.

The later exists as device memory isn`t backed by pages at least in Linux that means one can not pass array of page references to vmap() as these pages do not exist. That is why map_pfn() which accepts array of page indexes was created. I think the same can be applied to FreeBSD. IIRC while debugging this about year ago I got NULL pointer dereferences in vtoslab() called from is_vmalloc_addr() that is why is_vmalloc_addr() is changed in this review too. Unfortunately, github garbage-collected crash report so I am not absolutely sure of it.
If you are absolutely sure that PCI BARs are backed by vm_page-s, I'll redo the review in your way.

Only recent Intel A* use vmap_pfn(). I very doubt i915kms works on other than amd64 or i386

Which kind of BAR? If it is io BAR, then it is normally located in below 4G, which is covered by DMAP, and then keeping consistent caching attributes is crusial.

If it is an aperture-like BAR, which might be located in above 4G, which is typical for resizable BARs cards generation, then GEM needs to have PHYS_TO_VM_PAGE() working for many reasons, most important is the possibility of mapping it into userspace. So it must be registered with vm_phys_fictitious_reg_range().

That said, it is very easy to make pmap_qenter() to work with even unregistered uncovered by vm_page_array BAR:

void
f(vm_offset_t va, vm_paddr_r pa, vm_memattr_t mattr)
{
	struct vm_page fm;
	vm_page_t m;

	m = PHYS_TO_VM_PAGE(pa);
	if (m == NULL) {
		m = &fm;
		vm_page_initfake(m, pa, mattr);
	} else {
		pmap_page_set_memattr(m, mattr);
	}
	pmap_qenter(va, &m, 1);
}

I never hold this device in my hands. I think it is memory BAR as AFAIR mapped region was used to upload firmware blob to device with simple memcpy(), I do not know if it must be registered with vm_phys_fictitious_reg_range() or not. If it woudn't do a harm, I would add it to both map and unmap functions.

I am not sure that doing such malloc() is good idea.

If this might be used for mapping real apertures, I believe sizes like 1G and larger are expected. Now, for 1G on amd64, we need 1G/4096 == 256K vm_pages, which gives us sizeof(ma) == 256K*8 == 2M. This is on the edge of the reasonable size for the kernel malloc.

But for fma, where sizeof(struct vm_page) == 88, we get the allocation size of ~22M, which is too heavy. Kernel might not have that much contiguous KVA due to fragmentation.

Should this be MIN(count, VMAP_MAX_CHUNK_SIZE) instead? size dimension is bytes, not pages.

BTW we have mallocarray(9) which is begging to be used there

I am not saying that this is incorrect, but I am curious: what is pfn?

next mallocarray does not fit 80 column line, but malloc fits. It is safe to replace now as we caped allocation size.

This version limits fma size to 65536 to fit malloc zone

FreeBSD calls it page index