AIX Version 4.3 Differences Guide

It is also possible to have a situation similar to the preceding example, except
that the second remapping could touch fifteen segments, starting with ESID 2.
This case would fail the first pass, and a second pass becomes necessary to sort
them into ascending order. Although this second pass, when required, does add
some overhead, it guarantees that the ranges to be mapped will fit into fifteen
segments.
3.2.2.6 Remap Kernel Programming Interfaces
There are remapping programming interfaces that are exported to kernel
extensions from the kernel. These are primarily for use by the 64-bit kernel
extension; however, applications that add their own system calls will need these
as well. For this reason, these services take up regular namespace and are not
prefixed with an underscore. See the man pages for formal documentation of
these routines as_unremap64() is intended for kernel extensions that really need
to have the unremapped address.
The library-side maps 64-bit addresses to 32-bit in that it selects the sreg
numbers to correspond to the ESIDs of the 64-bit addresses. However, the
kernel-extension still has to update the address space map for the 64-bit thread
to reflect these values, so that when the kernel uses these 32-bit addresses to
access memory, the proper SID will be inferred. These services update the
MST-extension remap struct described previously:
int remap_64(struct remap r)
int remap1_64(struct remap r)
int remap2_64(struct remap r1, struct remap r2)
unsigned long long as_unremap64(uint addr32)
The reason for three different remap routines is to optimize for cases where only
one or two ESIDs are used. This is a very common case. The remap_64() call
handles the case of greater than two remap structs input as well as all other
cases. Parameters to remap1_64() and remap2_64() are passed entirely in
registers, so these routines do not have to copyin() a remap struct from
user-mode.
There is also an internal kernel routine, remap(), that is used by copyin64() and
others. The purpose of remap() is to support 64-bit-enabled code in the kernel
that handles non-remapped addresses. Code calling remap() passes the address
of a remap-like struct on the stack (typically), and this is used as a save area for
the regular MST remap fields that are overwritten by this remap() call. At the end
of the copyin64(), or any other call, restoremap() is called with the address of the
stack-resident remap-like struct. The original contents of the MST remap fields
that were temporarily overwritten are written back to the MST. An additional
internal routine, as_remapaddr(), is used to return the original 64-bit unremapped
address (modulo SEGSIZE) for a given 32-bit remapped address.
static void remap(ptr64 addr, uint nbytes, struct remaps * ptr)
static void restoremap(struct remaps * ptr)
ptr64 as_remapaddr(uint addr32)
These services take only one address and length to remap, and there is no place,
currently, where calls to remap() are nested without restoremap(). Only one data
structure at a time can be remapped in this fashion. The on-stack remaps
structure is able to store the entire mstext->remaps array when there are fifteen
segments total in the range to be remapped through savemap().
44 AIX Version 4.3 Differences Guide