Hi,
There is only a tiny amount of ram available in the permanent "low" area of ram (typically less that 64K). If the code has exhausted the permanent "high" ram (typically 256K) then it is likely to rapidly exhaust the low ram and cause a worse failure when code that requires a tiny amount of "low" space fails.
I disagree with “likely”.
So it currently fails with 16 controllers. This patch brings it how far? 20 controllers? It's not like this patch scales things up much.
Typical work arounds are to extend the amount of high ram available (see BUILD_MAX_HIGHTABLE) or to use malloc_tmphigh() and manually reserve the space in the e820 map.
I think this patch is good regardless if modifying BUILD_MAX_HIGHTABLE can be served as a workaround. (Also if it is a typical workaround, why isn’t it configurable as a Makefile parameter?)
Making this configurable (via kconfig) makes sense indeed.
I find it odd to allocate from malloc_tmphigh() and manually reserve the space in the e820 map. As it basically undermines the definition of the Temporary High-Zone which should not be reserved from OS and therefore must not be accessed after SeaBIOS initialisation phase.
pmm (see src/pmm.c) does this for large allocations.
Also, it is kinda hard to put the finger on which code you would change to use malloc_tmphigh() like this all the time. Will you do this change for example in pvscsi.c code?
The logic in pmm could be moved to malloc.c. Probably needs some refinements then, the current code is meant to handle rare and very large (megabytes) allocations. In case we run out of space on small allocations it probably makes sense to grab a block from the tmphigh zone, reserve it in the e820 map and add it to the high zone pool instead. So effectively the high zone can grow dynamically.
cheers, Gerd