[Cherry-Pick] UefiCpuPkg: Enable MM_CORE_STANDALONE for IntelMmSaveStateLib, SmmCpuPlatformHookLibNull

[apop5]

Description

MmSupervisorPkg's MmSupervisorCore.inf (MM_CORE_STANDALONE) uses Both SmmCpuPlatformHookLib and MmSaveStateLib.

Edk2 limited the scope of the libraries to not support MM_CORE_STANDALONE, and this works okay for the Edk2's StandaloneMmPkg, but it breaks the expectations of the MmSupervisorPkg's Core.

Add MM_CORE_STANDALONE as an allowed Module Type for these libraries.

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?
• Backport to release branch?

How This Was Tested

Building on silicon vendor codebase which consumed MmSupervisorCore.

Integration Instructions

No integration required.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Please upload report for BASE (dev/202502@c7881cf). Learn more about missing BASE report.

Additional details and impacted files

@@             Coverage Diff              @@
##             dev/202502   #1312   +/-   ##
============================================
  Coverage              ?   4.86%           
============================================
  Files                 ?     140           
  Lines                 ?   26732           
  Branches              ?     527           
============================================
  Hits                  ?    1301           
  Misses                ?   25407           
  Partials              ?      24           

Flag	Coverage Δ
UefiCpuPkg	4.86% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[os-d]

Instead of going in as reverts of edk2 commits should this go in as MU_CHANGEs?

[makubacki]

Instead of going in as reverts of edk2 commits should this go in as MU_CHANGEs?

Also, @apop5, are you going to make the upstream change to the allowed Standalone MM types? If so, I'd rather just make that be the MU_CHANGE since it is closer to what upstream will have.

[apop5]

Instead of going in as reverts of edk2 commits should this go in as MU_CHANGEs?

Also, @apop5, are you going to make the upstream change to the allowed Standalone MM types? If so, I'd rather just make that be the MU_CHANGE since it is closer to what upstream will have.

This revert is happening because SupvMM is attempting to consume these libraries.
StandaloneMmPkg does not attempt to consume them.
My hope is to rework the MM Supv to be more in sync with standalonemmcore, and that these changes can be dropped.

Alternatives are:
Make Stmm versions of these libraries (in the SupvMM package)

I don't think these changes should be upstreamed to edk2, because this is happening because SupvMM is attempting to consume them.

[makubacki]

I don't think these changes should be upstreamed to edk2, because this is happening because SupvMM is attempting to consume them.

I think that's why it should be supported. These are in UefiCpuPkg which should support all MM implementations. I don't see a reason the upstream needs to restrict the linking module types to exclude Standalone MM for these library instances.

[apop5]

I don't think these changes should be upstreamed to edk2, because this is happening because SupvMM is attempting to consume them.

I think that's why it should be supported. These are in UefiCpuPkg which should support all MM implementations. I don't see a reason the upstream needs to restrict the linking module types to exclude Standalone MM for these library instances.

I'll get a PR up for edk2

[apop5]

PR to edk2 is up

tianocore/edk2#10914