OvmfPkg/Sec: Skip setup MTRR early in TD-Guest

[sunceping]

With the commit ce4c76e (“OvmfPkg/Sec: Setup MTRR early in the boot process.”), we find an unexpected #VE is triggered in TD-Guest.

The background of importing the above commit is that: Before running lzma uncompress of the main firmware volume, if not correctly set MTRR, that would make the uncompress be extremely slow.
Detailed discussion info can refer to below links:
https://edk2.groups.io/g/devel/message/114202
https://edk2.groups.io/g/devel/message/114977

Refer to [intel-tdx-module-1.5-base-spec] Section 11.3 and section11.6.1, CR0.CD is enforced to 0 in TD-Guest. And refer to section 18.2.1.4, TDX module MTRR emulation enforces WB in VMM.

Currently the initial MTRR are:

• Td-Guest : MTRR disabled, Type is WB.
• Non-Td-Guest : MTRR disabled, Type is UC.

In DXE phase, OVMF/TDVF would check the MTRR Type for MMIO (in CpuSetMemoryAttributes -> MtrrGetMemoryAttribute -> MtrrGetMemoryAttributeworker:
https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/MtrrLib/MtrrLib.c#L929 ).
If MTRR is disabled, it always returns UC. Otherwise, it returns the actual value.

If it checks that the type is not UC then the MTRR is programmed. It is required to disable cache by setting CR0.CD to 1. That will trigger an unexpected #VE in TD-Guest.

Based on above analysis we propose to skip "Setup MTRR early" in TD-Guest because of:

• TD-Guest doesn’t have the issue that lzma uncompress extremely slow.
• This patch will trigger an unexpected #VE in TD-Guest.

intel-tdx-module-1.5-base-spec:
https://cdrdv2.intel.com/v1/dl/getContent/733575

Cc: Erdem Aktas [email protected]
Cc: Jiewen Yao [email protected]
Cc: Min Xu [email protected]
Cc: Gerd Hoffmann [email protected]
Cc: Elena Reshetova [email protected]

Description

<Include a description of the change and why this change was made.>

<For each item, place an "x" in between [ and ] if true. Example: [x] (you can also check items in GitHub UI)>

<Create the PR as a Draft PR if it is only created to run CI checks.>

<Delete lines in <> tags before creating the PR.>

• Breaking change?
  • Breaking change - Will this cause a break in build or boot behavior?
  • Examples: Add a new library class or move a module to a different repo.
• Impacts security?
  • Security - Does the change have a direct security impact?
  • Examples: Crypto algorithm change or buffer overflow fix.
• Includes tests?
  • Tests - Does the change include any explicit test code?
  • Examples: Unit tests or integration tests.

How This Was Tested

<Describe the test(s) that were run to verify the changes.>

Integration Instructions

<Describe how these changes should be integrated. Use N/A if nothing is required.>