Account for latest changes in D54650.

• constify command nvlist_t argument
• adapt vm_do_checkpoint to use the new return type

Account for latest changes in D54650.

Address @rew 's comments - change IPC command return type to nvlist_t.

Address @rew 's comments.

Address @rew 's comments.

Address @markj 's comments.

In D27220#1233531, @kib wrote:

Any progress with testing?

In D53728#1231626, @olce wrote:

There are already inline comments asking for a comment on the current limit. If possible, I think it would be great also to explain the point of this resource limit. In particular, which resources a VMM consumes that is not already accounted into existing resource limits, such as for memory: RLIMIT_AS, RLIMIT_RSS, RLIMIT_STACK, or CPU: RLIMIT_CPU? I suspect some kernel memory? Are there hardware limitations to the number of VMs that can be created?

Address @olce 's comments.

Defer incrementing the vmm counter.

Address @markj 's comments.

Address @markj 's comments.

Address @markj 's comments

Address @markj 's comments.

Address @markj 's comments.

Address @emaste 's comment.

Rebase.

Address @corvink 's comments.

One minor thing I've noticed is that we don't export M_NOWAIT.
I think it would be very useful to have a way of controlling whether we wait or exit on failure, but I'm not sure if accomplishing that is as straightforward as defining M_NOWAIT in sys/vmem.h.

In D27220#1212532, @kib wrote:

In D27220#1212528, @bnovkov wrote:

Hi, is there a concrete reason why this revision never landed or has it just slipped through the cracks?

I would really like to use libuvmem for one of my ongoing bhyve projects and would like to see this land, let me know if there a way I could help with that.

The intent of the libuvmem port was to use vmem allocator for bhyve to handle physical address space. That stalled, and I do not see a reason to add unused library to base.

Hi, is there a concrete reason why this revision never landed or has it just slipped through the cracks?

LGTM overall (aside from the race issues that you'll handle in a separate PR).
I tested the changes with stress2 in a NUMA VM for a couple of hours and didn't run into any obvious issues.

In D44566#1188985, @saper_saper.info wrote:

Is it possible that this broke grub2-bhyve built for older FreeBSD 15-CURRENT? https://lists.freebsd.org/archives/freebsd-current/2025-August/008456.html

Could we add something to RELNOTES/UPDATING to say this happened? Did we bump FreeBSD version for this one?

(a rebuilt ghub2-bhyve with libvmmapi.so.7 works fine)