Looks good now, thanks! I only have one minor inline comment.

Thanks, LGTM now. I won't be able to test the patch series on a non- SiFive FU74 board until EuroBSDCon finishes, I'll let you know if anything comes up during testing.

Propagate error from bounds checking instead of aborting

In D59068#1357257, @bnovkov wrote:

In D59068#1356482, @kp wrote:

I'm also struggling to make sense of the baseline flame graph. It seems to be spending a lot of time removing interfaces (5% of samples in pf_kkif_free()!) and I don't see any calls to pf_test(), which we should see if we were handling traffic.
Maybe the address decoding went wrong, because those stacks just look wrong.

Hm, that's odd. I'll try to find out what went wrong.

In D59068#1356482, @kp wrote:

I'm also struggling to make sense of the baseline flame graph. It seems to be spending a lot of time removing interfaces (5% of samples in pf_kkif_free()!) and I don't see any calls to pf_test(), which we should see if we were handling traffic.
Maybe the address decoding went wrong, because those stacks just look wrong.

Address @kp 's comments

This is a good feature, but I don't think that this is the correct approach design-wise. Adding an ioctl handler to just to fetch a VM's PID is overkill IMO, new ioctl commands should only be added when there's no other way to obtain the needed information (e.g., fetching memsegs and other metadata that is stored in the vmm module).

In D54641#1353031, @jhb wrote:

In D54641#1344584, @bnovkov wrote:

In D54641#1344263, @jhb wrote:

When a new PCI device shows up in hotplug both for native PCI-e hotplug and other systems like the ACPI approach you are using, the new device just shows up with all decoding disabled and the BARs set to their reset values (address of 0). It is the guest OS's job to allocate address space for the BARs and manage the address space.

Thank you, this clears up a lot and I think I'll be able to simplify the whole patch series greatly since we can completely ditch vmem.
Before I start purging the vmem-related parts from this patch stack, do you think that there's a future use for this application of vmem that would justify keeping it?

Probably not TBH as this is just a one-time allocation vs an address space that needs updating.

In D59068#1354800, @bofh wrote:

Can you check or host the results somewhere else? Maybe freefall?

Address @kevans 's comment

Address @mmel 's comments

In D58788#1348916, @markj wrote:

Thanks, I've run into this problem too.

Rather than forwarding signals, why not have a pipe shared between the two processes? The child process can use it to detect when the parent goes away, and exit automatically. That should be simpler and will work for all cases where the parent exits (assertion failure, SIGKILL, etc.).

Address @markj 's and @kib 's comments

In D57624#1336128, @markj wrote:

Did you microbenchmark the new implementation? I'd be curious to know, say, how many cycles it takes to execute 10000 back-to-back 4KB page invalidations using the old and new implementations respectively, when the target CPU mask is just the current CPU and when it's the set of all CPUs.

In D54641#1344263, @jhb wrote:

When a new PCI device shows up in hotplug both for native PCI-e hotplug and other systems like the ACPI approach you are using, the new device just shows up with all decoding disabled and the BARs set to their reset values (address of 0). It is the guest OS's job to allocate address space for the BARs and manage the address space.

LGTM, but I'd wait for at least one member of manpages to take a look.

In D57741#1339463, @thebugfixers_pm.me wrote:

Anyway, coming quickly back to your actual question I guess I must have thought at the time that touching cat might also eventually land me unwelcome attention for daring to touch a long-standing binary if they came looking for me on other diffs, so it was quite possibly a pre-emptive abandoning.

@emaste are there any other blockers here other than your comment? The fix is quite straightforward and I see no reason not to land this.

Why was this review closed? The issue wasn't resolved in the meantime and I see no reason not to land this.

Address @glebius 's comments

In D58305#1337458, @pouria wrote:

@bnovkov Should I wait for you to test, or are we good to land this?

Address @glebius 's comments

Add missing const qualifiers

Address @mmel 's and @mhorne 's comments.

In D58306#1337245, @bz wrote:

Please see the wireless mailing list where I sent a patch for test and did not get feedback. Changing the driver is the wrong thing to do (not that it works well currently).

https://lists.freebsd.org/archives/freebsd-wireless/2026-July/004328.html

Account for EINPROGRESS

In D58281#1337131, @glebius wrote:

In D58281#1337102, @bnovkov wrote:

Thank you for the offer, but I was trying to avoid unnecessary churn if the same thing can be achieved with ifa_ifwithnet. If you have future uses for a fib-aware version of ifa_ifwithaddr() I can implement it as well.

There will be less churn if you use standard KPI in the right place instead of current version. Pouria also needs this function. Even if he didn't, still creating this KPI on the first need is the right thing to do.

In D58281#1337090, @pouria wrote:

In D58281#1336902, @bnovkov wrote:

In D58281#1336697, @glebius wrote:

Instead of calling fib4_lookup() that has a different purpose, we need ifa_ifwithaddr() version that has fibnum argument.

Looking through net/if.c I noticed that ifa_ifwithnet seems to match what you're suggesting here, do you think we can use this function instead of adding a fibnum-aware version of `ifa_ifwithaddr()`?

I'll create a fib-aware version of ifa_ifwithaddr() and will let you know.

In D58281#1336697, @glebius wrote:

Instead of calling fib4_lookup() that has a different purpose, we need ifa_ifwithaddr() version that has fibnum argument.

Looking through net/if.c I noticed that ifa_ifwithnet seems to match what you're suggesting here, do you think we can use this function instead of adding a fibnum-aware version of `ifa_ifwithaddr()`?