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)

Address @markj 's comments.

Remove stray newline.

Add O_WRONLY check in hash_get and add corresponding tests.

Address @markj 's comments.

In D46607#1165023, @markj wrote:

Looks ok to me with the man page nits fixed.

Rework and clarify interactions between the -m flag and individual domain memory sizes.

Closing this since it was superseded by D49531.

In D44567#1172416, @markj wrote:

Have you tried booting a Linux guest with NUMA configured?

Address @markj's comments

Address @markj 's comments and fix an edge case where VM_LOWMEM_LIMIT == 0 .

Address @markj 's comments.

Address @markj 's comments:

• Remove cpu affinity tracking

I have reworked the acpi.c changes in a way that simplifies tracking cpu affinities (and allows us to get rid of libvmmapi cpu affinity interfaces).

Address @markj 's comments and rework acpi.c changes:

• acpi.c now tracks each 'vCPUid->domain' mapping
• New mappings can be added using acpi_add_vcpu_affinity
• Manpage fixes

One minor thing that wasn't mentioned here (and is likely be brought up in future C++ reviews) is the order of C++ includes. More specifically, should the C++ standard library includes come before or after /usr/include files?

I left a couple of comments about a few things that stood out in the first pass, I will likely have more as I dive into the internals.

Address @markj 's comments.