AIX Version 4.3 Differences Guide

Three interfaces exist, rather than just one, to improve performance on
remapping. For the case of syscalls that require only one or two parameters to be
remapped, the parameters may be passed in registers. This avoids the copyin()
to the kernel by remap_64() of a kremap struct and is a significant performance
saving. So, __remap1() or __remap2() should be used when only one or two
parameters require remapping, respectively. The __remap() call should be used
for syscalls requiring three or more remappings.
Like other things in 64-bit libc.a, __remap() is only available to applications
running in 64-bit mode and linked with the correct library. The input to __remap()
are the 64-bit addresses to remap in the addr structs (in uremap). The __remap()
code fills in the addr structs with remapped 32-bit addresses. It also fills in the
kremap struct with the 64-bit ESIDs in the slot corresponding to the 32-bit sreg
number that __remap() picked for the remapping. Slot 0 of the kremap struct
corresponds to 32-bit sreg 1. This is because sreg 0 is never given out for
reasons previously stated having to do with NULL pointers. As such, only fifteen
different segments can be remapped with one kremap struct.
There is no formal provision at the moment for remapping a given user-mode
address to a specific remapped address specified by the library. It is expected
that applications can avoid dependencies such as this. In the event that this is not
possible, two alternatives exist; add a new force-remap service, or create a
kremap structure with the specified remapping as though it had already been
processed by __remap().
3.2.2.5 Remap Optimization for Multiple Addresses
If more than one item must be remapped, there is a folding optimization done by
__remap(). For the second, and subsequent addresses in the uremap struct,
__remap() determines whether the ESID of the address being operated on has
already been remapped. If so, there is no need to make another kremap entry for
it.
The preceding works fine for circumstances where segment crossings are not
involved. It does, however, become complicated when you put
segment-crossings into the equation. Assume that __remap() is to process the
uremap struct in array-order. The addresses will not be sorted. Also assume that
the first parameter, which does not cross a segment boundary and resides in
64-bit ESID 3, becomes remapped to 32-bit srno 1. If the second parameter does
cross a segment boundary and starts at 64-bit ESID 2, in the absence of any
special optimizations, this second parameter would have to be remapped to
32-bit srnos 2 and 3 (0 is unavailable for use). Note that the second parameter
must occupy adjacent 32-bit segments.
There are several ways around this problem. One way is to have __remap()
presort the input addr structs by ascending address, but this could get expensive,
since it could have a virtually unbounded number of input address structures to
process. The actual __remap() implementation is a two-pass method. The first
pass (for a majority of the cases) takes a simple approach. In the preceding
example, it would simply associate the 32-bit srnos 1, 2, and 3 as explained. As
long as the rest of the remappings fit in the maximum fifteen slots that are
available, this is not a problem, and there is no expensive sorting or
post-processing required. The simple first pass will do folding only as far as
checking to see if the 64-bit ESID has been remapped.
64-Bit Enablement 43