Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34257 )
Change subject: cpu/x86: Define INSTALL_SMM option ......................................................................
Patch Set 2:
Patch Set 2:
Don't build smm -class. Absolute minimal resident SMM may be installed, like asm inline "rsm"? Let MP init raise SMIs to relocate SMM stacks? On entry to payload, SMRAM can be locked or left unlocked.
Is this behavior a long term goal?
I just noticed that it was pretty hard to try evaluate what is built into SMM currently with all the guards in place. I think we would want to separate SMM to rmodule file in CBFS. Things should be stable enough such that one may use audited SMM build from previous build, yet update ramstage as needed?
Also with the experiments/initiatives to leave SMM loading to OS, I'd like to see that platforms at least pass the build in such a use case. Currently HAVE_SMI_HANDLER=n mostly will not build.
What definition do we have HAVE_SMI_HANDLER to be going forward? That it can support SMM? And we want to turn off the permanent handler installation with INSTALL_SMM?
I think HAVE_SMI_HANDLER would indicate platform code has support to raise and configure SMIs. Essentially, satisfy the requirements of PARALLEL_MP code.
I think the combinations seem legit, but I think the naming could be more descriptive in what we're aiming for.
Sure.