In D53817#1229564, @brooks wrote:

In D53817#1229561, @markj wrote:

How should ptraddr_t and vm_offset_t coexist? Are they semantically different, or should we gradually replace uses of vm_offset_t with ptraddr_t, or?

Right now vm_offset_t is inconsistent and sometimes equivalent to a ptraddr_t and sometimes to a uintptr_t. In CheriBSD we've converted a significant number of vm_offset_t's to a new vm_pointer_t because we need provenance preservation. I think @jhb wants to convert many of those into void *, but I'm a little unclear on the overalls scope. @alfredo.mazzinghi_cl.cam.ac.uk thinks we do end up with vm_pointer_t at least for a while as too much math is done on those for using void * to be comfortable.

D53818 actually does redefine vm_offset_t to ptraddr_t which isn't quite right, but will be once I extract the vm_pointer_t patches.

There's a bigger long term question if vm_foo_t should exist at all. I don't have a strong opinion there.

In D43711#998275, @kib wrote:

Do you have somebody to commit this for you?

If not, please mail me git-format-patches.

Fix additional freeuio() calls in compat/freebsd32.

In D43711#996954, @kib wrote:

I do not have much objections against this change, but I wonder what do you mean by 'changing the sub-allocation layout'. Note that uio->uio_iov is often modified during uio life, resulting in the pointer no longer pointing to the initial iov vector at the time of uio allocation.

Dropped #ifdef PHYS_HAS_DMAP for the PHYS_SZ_IN_DMAP macro definition.

Move PHYS_SZ_IN_DMAP to the machine-independent vm/vm_param.h

Fixed off-by-one check for the DMAP limit.

Should now be fixed. I misinterpreted the desired behaviour for PHYS_SZ_IN_DMAP.

Added the PHYS_SZ_IN_DMAP macro as requested.

@kib Do you have any further comment?

In D40110#916824, @mhorne wrote:

LGTM, thanks. I can push this to the main branch.

Can you update the title+summary to reflect the final diff? (We didn't end up changing the devmap size.) Even easier would be if you could just send the git format-patch output to me over email: mhorne@freebsd.org.

Shrink the size of PMAP_MAPDEV_EARLY_SIZE to a single L2_SIZE.
This should be acceptable given the fact that it does not seem that we were
trampling the DTB mapping before.
While this solution is less robust, it avoids adding complexity to asm code
unless it is absolutely required.
Added assertions that verify that both the DTB and early DEVMAP are aligned to
L2 boundary and that the DTB mapping does not overlap the DEVMAP.
This check assumes that the DTB only consumes a single L2 entry.

@mhorne I'm not sure how this currently is supposed to work, because the PMAP_MAPDEV_EARLY_SIZE constant is already larger than L2_SIZE in vmparam.h. So what we really want is also the DTB to be mapped at VM_EARLY_DTB_ADDRESS, which currently seems to be assumed to correspond to the second-to-last L2 entry in the devmap table. Is the PMAP_MAPDEV_EARLY_SIZE constant supposed to contain VM_EARLY_DTB_ADDRESS?

Looks good to me.