libvmmapi: Make memory segment handling a bit more abstract

[markj]

Summary

libvmmapi leaves a hole at [3GB, 4GB) in the guest physical address
space. This hole is not used in the arm64 port, which maps everything
above 4GB. This change makes the code a bit more general to accomodate
arm64 more naturally. In particular:

• Remove vm_set_lowmem_limit(): it is unused and doesn't have well-defined constraints, e.g., nothing prevents a consumer from setting a lowmem limit above the highmem base.
• Define a constant for the highmem base and use that everywhere that the base is currently hard-coded.
• Make the lowmem limit a compile-time constant instead of a vmctx field.
• Store segment info in an array.
• Add vm_get_highmem_base(), for use in bhyve since the current value is hard-coded in some places.

No functional change intended.

[jhb]

I do wonder if we want to make even the libvmmapi interface more abstract where the exposed APIs take a segment index. Ideally you'd not even call it highmem on arm64, but only care about lowmem on x86. I'm thinking a bit of how we do this in the kernel where use MD macros to enable certain freelists (where x86 has an extra freelist for the low 1MB IIRC)

lib/libvmmapi/vmmapi.c

449

This could also maybe be a for-loop?

482

Seems like this could be a for loop over the ctx->memsegs array now?

[corvink]

lib/libvmmapi/internal.h

23

Adding a limit would allow us to make this code more generic. We could create a MD array for the memsegs like we did for ioctls in libvmmapi.

lib/libvmmapi/vmmapi.c

425

This could be a for-loop too when adding a limit to memegs:

size_t remaining = len;
for (i = 0; i < nitems(ctx->memsegs); ++i) {
  if (remaining < ctx->memsegs[i].limit - ctx->memsegs[i].base) {
    ctx->memsegs[i].size = remaining;
    break;
  }
  ctx->memsegs[i].size = ctx->memsegs[i].limit - memsegs[i].base;
  remaining -= ctx->memsegs[i].size;
}

506

This could use a for-loop too.

535

This functions seems to be unused.