David Hendricks has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/41829 )
Change subject: cpu/x86/smm: Enable SMM support for Xeon-SP ......................................................................
Patch Set 8:
(2 comments)
The main decision made at runtime is do we have enough space for all the CPUs? The TSEG base and LIMIT are programmed by the FSP. At compile time, we do not know the size of SMM.
FSP... *sigh*
The rest of the calculations can be done ahead of time assuming in the future HW doesn't require any runtime checks based on some capability flag. If so, then we are doomed as architecture can't handle it. Having a SMM architecture that can adapt dynamically is preferred by me. However, it would be great to get other's input on this. One thing is clear, the existing SMM loader architecture does not scale. Having two SMM loaders, one legacy and one new is a good way to transition into the new one as products need to do so.
As I see it, the goal here is simply to improve on top of the existing module loader to cope with newer processors. Re-designing this whole thing as a linker script should be done in separate patch.
That said, this touches common code and presents a risk so making this "v2" seems reasonable. If we do that then someone (possibly me) can annotate the v1 code and nudge developers toward this version.
https://review.coreboot.org/c/coreboot/+/41829/6/src/cpu/x86/smm/smm_module_... File src/cpu/x86/smm/smm_module_loader.c:
https://review.coreboot.org/c/coreboot/+/41829/6/src/cpu/x86/smm/smm_module_... PS6, Line 130: sizeof(cpus)/sizeof(struct cpu_smm_info) You can also use ARRAY_SIZE() from commonlib/helpers.h.
https://review.coreboot.org/c/coreboot/+/41829/8/src/cpu/x86/smm/smm_module_... File src/cpu/x86/smm/smm_module_loader.c:
https://review.coreboot.org/c/coreboot/+/41829/8/src/cpu/x86/smm/smm_module_... PS8, Line 327: . ).