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/114202https://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 <erdemaktas@google.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
071d2cfab8