For historical context, introduced in rG:12bc222e5720dd2c4672a119f56024a86775414d. This change is indeed fine because "we are sufficiently confident that the checks in namei() are correct." If they were not, we have bigger problems.

Address review comment

In D59815#1374524, @kib wrote:

In D59815#1374449, @markj wrote:

Presumably sysarch.2 should also be updated.

Rather, it should be written. Or might be sysarch.x86.2. Right now the man page is a stub that proclaims the existence of the syscall.
I might do it later.

In D59815#1374449, @markj wrote:

Presumably sysarch.2 should also be updated.

Good catch.

Clean up

Added test cases

Fix other panics found during testing

Presumably sysarch.2 should also be updated.

I prototyped something in D59883

This was also tested on

(uarch synth) = Intel Emerald Rapids {Raptor Cove, optim of Golden Cove}, Intel 7
(synth) = Intel Xeon Scalable (5th Gen) Bronze/Silver/Gold/Platinum (Emerald Rapids A1/R1) {Raptor Cove, optim of Golden Cove}, Intel 7

which has the splitlock control.

Update fcntl.2.

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

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)

The portion of the changes related to hmp(4)'s score was merged via the fix at https://reviews.freebsd.org/D44456#1374396.
The remaining parts of the change address the hmp(4) capacity-related code that was removed in https://reviews.freebsd.org/D44456#1374396; this code does not exist in the latest version of intelhfi(4).

• Remove code related to getting and setting the capacity value for hmp(4).
  • This code is being removed with the intention of implementing it in hwpstate_intel(4) in the future.
• Create a mapping table between CPU cores and HFI tables, and improve the code to avoid relying on the SMP CPU topology.
  • Due to a misunderstanding of the intel HFI's specifications, I had mistakenly referenced the CPU group from the SMP(4) CPU topology, whereas I should have retrieved the index pointing to the per-core HFI table from the MSR. Sorry.

• Revert the 'intelhfi' line added to the 'sys/amd64/conf/GENERIC' file. ( I have made revisions based on the comment (https://reviews.freebsd.org/D56546#1341348) received.)

In D55012#1357788, @denis.borovikov_gmail.com wrote:

Hi,

I just submitted a DRM/KMS port of the linux virtio-gpu driver (2D) to
drm-kmod: https://github.com/freebsd/drm-kmod/pull/499. sway works with
the pixman renderer under UTM/QEMU on 15.1 aarch64. Looks complementary
to this patch (console and X via scfb here, KMS/wayland there), happy
to coordinate.

Re the extra wakeups discussion - the drm path ends up being what
andrew suggested: updates are driven from userspace, the compositor
sends explicit damage and the driver only transfers what changed, so
there is no periodic flush. Doesn't help the scfb case of course, but
wayland users won't need the refresh timer once drm-kmod has the
driver.

Denis

I tested this on real hardware, with the exception of a few -* variants, but Linux handles them the same way. (I can also get that hardware in the next days.)

fcnt.2 should list renameat(2) in FD_RENAME_BENEATH description

Note: Ideally, at some point, we should add some way to print the IP blocks per generation (separate change/revision).

include the full patch

In D59695#1370984, @mhorne wrote:

Glad to see this moving forward. I only skimmed the overall structure, and in particular I am not confident about MSI code.

My main concern is about this 'pool' mechanism. Why is it important to preallocate these irqsrc structures, and is there any way to be smarter about it (upper bound, or runtime expansion of the pool as-needed?). Unless I am mistaken there is not a high reuse rate.

remove irq pool to simplify operation. Allocate and register IRQs on demand