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.

Looks good to me, thank you for working on this. I'll follow up on this with a patch that fully incorporates the uses of RLIMIT_VMM into the setrlimit(2) machinery tomorrow.

In D57031#1306916, @jilles wrote:

It feels a little weird to clutter up ulimit -a and limits with a limit for this pretty exotic feature.

In D55038#1307085, @jilles wrote:

I would say this should be fixed by clarifying the man page. For me, it's clear that all rlimits only apply to the current process and its children, while the tracking is per real UID for some of the limits.

I disagree, the man page can only paper over the fundamental problem that arises from mixing limits with different scopes in a system call that only operates on one of them.
Let's say that you're faced with a situation where you suddenly need to drastically lower a per-UID limit for a user and have it take effect immediately. How are you going to accomplish this with the way we currently handle per-UID limits?
Changes to the limit value in login.conf will only apply to new sessions, which is a problem and a IMO big flaw in our current implementation.
Having a mechanism for enforcing per-UID limits but not being able to change the limit's value and have it take effect for that UID immediately makes no sense.

In D55038#1306915, @jilles wrote:

With the existing rlimit functionality specified by POSIX, I can, as a user, defend against a forkbomb or prevent forks/kqueues entirely in a particular process subtree. A system administrator can also set resource limits which will be applied at login or service start.

Rebase

Rebase and address @brooks 's comment.

Address @markj 's comment.

Address @markj 's comments.

Rework patch - flushing the TLB when inserting a new mapping fixes the original issue.

In D56925#1303888, @jrtc27 wrote:

The Vector spec does not require any ordering on the memory accesses performed, so a legal implementation could alternate which address faults and this would never make forward progress.

Was this change motivated by this comment in PR290920 and have you tested this patch somehow yet?
If not, I think that commenter would be more than willing to test it.

In D47678#1280070, @emaste wrote:

@bnovkov do you know why the "needs close" check determines this one has already landed? (i.e. fbsd_author_needs_close.html)

In D55641#1276922, @ali_mashtizadeh.com wrote:

Looks good to me, just be aware that I landed a fix that forces us to whitelist json fields. I don't see any new fields but you should check that it builds against head as of bfb2fd5f66183454cfe8771595df09c0f23c7efb

Remove redundant errno save

In D54641#1263851, @markj wrote:

I guess this mostly relates to support for legacy and 32-bit guest operating systems? I tend to think it's undesirable to break support for them, given that virtualizing legacy systems is a major reason to use bhyve in the first place, at least in principle.

Does it simplify things at all to use a single vmem arena for both 32-bit and 64-bit memory BARs, and apply constraints as needed when calling vmem_xalloc()?

Fix PCI passthrough:

• Introduce a state machine that tracks a BAR's address. This allows us to properly release and allocate BAR addresses from the appropriate pool when the guest starts migrating BARs
• Comply with the remark in pci_emul_assign_bar and allocate small MEM64 BARs from the MEM32 pool
• Allow the guest to move an already allocated BAR to a new address

In D54641#1258945, @markj wrote:

Have you tested with PCI passthru configured? With just this patch applied, I get an assertion failure in update_bar_address(). Same result if I test your github branch.

LGTM.

Address @markj 's comment - switch to INTERNALLIB

Address @markj 's comments.

Address @markj 's comments.

In D54641#1258945, @markj wrote:

Have you tested with PCI passthru configured? With just this patch applied, I get an assertion failure in update_bar_address(). Same result if I test your github branch.

Address @markj 's comments.

Address @markj 's comments.