Re: [RFC] EAL: legacy memory fixed address translations

[Don Wallwork <donw@xsightlabs.com>]

On 7/27/2022 4:36 PM, Dmitry Kozlyuk wrote:
> I now understand more about_why_  you want this feature
> but became less confident_what_  do you're proposing specifically.

Let me try to give a trivial example of how it would work
to make sure we're on the same page and then we can get
back to details..

Say you have a system with 4 huge pages that are 1G each
and the physical addresses are 10, 11, 17 and 22G.  If we
map 13G of virtual address space, that will be enough to
cover all of the huge page physical addresses.

If the VA region starts at 1G, all of the hugepage PAs can
be mapped into that region as shown below under Proposed
heading.  For comparison, existing mapping that would be
done in legacy mode is shown under the Current heading.

Proposed      Current (Legacy)

  VA | PA         VA | PA
----+----       ----+----
  1G | 10G        1G | 10G
  2G | 11G        2G | 11G
  3G |  -         3G |  -
  4G |  -         4G | 17G
  5G |  -         5G |  -
  6G |  -         6G | 22G
  7G |  -
  8G | 17G
  9G |  -
10G |  -
11G |  -
12G |  -
13G | 22G

So in this example, we have a fixed offset of 9G to translate
between VA to PA or vice versa.This works whether the huge
pages happen to be allocated statically (legacy mode) or
dynamically.

The unused VA address space from 3G-7G and 9G-12G can be
unmapped in just two unmap calls.

This is a very nice property in that it makes address
translations trivial without requiring costly searches.
This property also makes debugging easier.