[L] Change in coreboot[main]: drivers/smm_payload_interface: Add initial support for SMM payload

[Benjamin Doron (Code Review)]

Attention is currently required from: Arthur Heymans, Martin L Roth, Michał Żygowski, Patrick Rudolph, Sean Rhodes.

Benjamin Doron has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/70378?usp=email )

Change subject: drivers/smm_payload_interface: Add initial support for SMM payload
......................................................................

Patch Set 18:

(3 comments)

Commit Message:

https://review.coreboot.org/c/coreboot/+/70378/comment/ab268084_b18da85b :
PS18, Line 37: - coreboot provides register definitions in CBMEM to avoid
             :   silicon-dependence in payload.
> I don't think coreboot informing the payload should be done in this case. […]

I'd rather avoid the tedious maintenance burden associated with this. At best, whenever Intel/AMD release new chipsets, we'd be adding PCIe device IDs to some long switch case. At worst, we'd be copying a pile of register definitions into the payload, when this was already done as part of coreboot SoC bring-up.

I don't mind changing the format, but I think it may become irrelevant if we replace it with our follow-up work.

File src/commonlib/include/commonlib/coreboot_tables.h:

https://review.coreboot.org/c/coreboot/+/70378/comment/0978652b_4e1c2191 :
PS18, Line 620: lb_pld_smram_descriptor_block
> what is this? Are there systems that can have multiple SMRAM regions?

It's an EDK2 concept: it could be used to support multiple SMRAM regions, sure. In practice, it's often used for marking one region as reserved/allocated.

Here, we reserve a page of memory to share a struct between bootloader and payload.

The offset of the shared region is already shared as part of another table, so, I can rework this so that coreboot is not implementing EDK2-specific details.

File src/include/smm_payload_interface.h:

https://review.coreboot.org/c/coreboot/+/70378/comment/a936269c_1fd02f49 :
PS18, Line 43: truct CPU_SMMBASE {
             : 	uint32_t ApicId;
             : 	uint32_t SmmBase;
             : };
             : 
             : struct SMM_S3_INFO {
             : 	uint8_t SwSmiData;
             : 	uint8_t SwSmiTriggerValue;
             : 	uint16_t Reserved;
             : 	uint32_t CpuCount;
             : 	struct CPU_SMMBASE SmmBase[0];
> Any reason to deviate from coreboot style?

I copied the struct used from EDK2, and didn't change it.

Again, this may become irrelevant if we replace it with our follow-up work.