Patch Set 1:

Three scenarios to consider:

a) INSTALL_SMM=y, HAVE_SMI_HANDLER=y

Current (unfortunate) situation. Build and install smm -class. Let MP init raise SMIs and do its job.

b) INSTALL_SMM=n, HAVE_SMI_HANDLER=y

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?

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 the combinations seem legit, but I think the naming could be more descriptive in what we're aiming for.

c) INSTALL_SMM=n, HAVE_SMI_HANDLER=n

Not possible for MP init to raise SMIs.
See CB:34152 and CB:34158 what is required on source level.
Little benefits in comparison to b) above?

View Change

1 comment:

• File src/cpu/x86/Kconfig:

  • Patch Set #2, Line 89: INSTALL_SMM

    I think we probably need a more descriptive name. RICH_PERMANENT_HANDLER ? FULL_PERMANENT_HANDLER ?

To view, visit change 34257. To unsubscribe, or for help writing mail filters, visit settings.