The cbmem utility has inherited some workarounds that originated
from the default 1 MiB mapping always working. This 1 MiB mmap
won't necessarily succeed if the 1 MiB encroaches on a subsequent
memory range that has different cacheability.
To fix this, map in only 4 KiB when the table size is not known which is
the case for any forwarding entry or any low table entries on x86. That
smaller mapping is then searched for a valid header. Once a valid header
is found the full table is mapped and parsed allowing a forwarding entry
to take precedence.
Lastly, the lbtable is kept mapped in such that other operations can
just operate on mapping that was previously parsed.
In order to allow multiple in-flight mappings a struct mapping was
added which caused the ripple within the code. However, there shouldn't
be any more reasons for putting weird heuristics for when to fail. If
the tables are bad then it's very much possible that mappings will fail.
Retrying when the exact sizes are already known won't fix those issues.
BUG=b:66681446
Change-Id: Ica0737aada8dc07311eae867e87ef2fd24eae98d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21718
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
46300aa2ce