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()`?

In D57692#1335508, @ziaee wrote:

Thanks for helping with it. Can I land it instead? This is part of GCE C4A turnup.

Avoid clearing CPU mask for range invalidation

Address @markj 's comments

In D57623#1325383, @mhorne wrote:

Is this implemented on the Spacemit K1 ?

Rename 'vms' to 'vmm'

LGTM, I'll split this up into two separate commits and land it tomorrow if there are no additional objections by then.

In D57887#1333560, @slw_zxy.spb.ru wrote:

The patch is updated to match all your last comments. What needs to be done from my side to get it pushed to main?

Two broader points:

• Please check for missing license headers and convert the existing ones to the shorter form listed in style(9)
• sys/sys/kernel.h has a bunch of unnecessary changes

LGTM, provided that @kib has no complaints.

I have no further suggestions or complaints after this one, I think we can land this after it's addressed, provided there are no complaints from anyone else.

Address @markj 's and @mhorne 's comments:

• add an svinval-aware pmap_invalidate_page variant
• remove awkward atop conversion

Two more nits, looks good otherwise.

One more thing, could you please document this feature in bhyve's manpage?

Address @markj's comments

In D51635#1315903, @ae wrote:

I think this commit breaks the case, when cursor is not yet set:

R_NEXT  Retrieve the key/data pair immediately after the cursor.
        If the cursor is not yet set, this is the same as the
        R_FIRST flag.

at least we found that now it is required to pass R_FIRST in the read loop:

+       flags = R_FIRST;
-       while ((ret = dbh->seq(dbh, &keycol, &valuecol, R_NEXT)) == 0) {
+       while ((ret = dbh->seq(dbh, &keycol, &valuecol, flags)) == 0) {
+               if (flags == R_FIRST)
+                       flags = R_NEXT;

otherwise the application didn't see any entries in db file.

Address @ivy 's comments and fix a a build failure in pci_virtio_scsi_ctl.c.

Simplify control flow

Address @markj 's comments.

@markj after chasing down a few issues you pointed out, I've decided to opt for the pmap_klookup approach instead since I think it's a more straightforward solution.

Address @markj's comments.

@markj I know it's been a while, but could you take another look at the updated BAR management scheme? My last testing runs with ppt devices were successful, but I've yet to re-test the patch after this rebase.

Rebase

Rebase

In D57177#1311153, @mhorne wrote:

Seems good to bring these in.

Are you running with mainline u-boot? I have not kept track of its status for this hardware.

Address @mhorne 's comments.

This partially overlaps with D57067. Let me know how you want to handle the overlap.

Address @markj 's comment.