]> git.proxmox.com Git - mirror_edk2.git/commit - OvmfPkg/OvmfPkgX64.fdf
OvmfPkg/OvmfPkgX64: Adjust load sequence of TdxDxe and AmdSevDxe driver
authorMin Xu <min.m.xu@intel.com>
Thu, 21 Apr 2022 00:45:29 +0000 (08:45 +0800)
committermergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Thu, 21 Apr 2022 01:17:38 +0000 (01:17 +0000)
commit892787fed516a147f3edfd2bb4fa0cf67c599be6
tree704601aa48261fe8d87120e1057c11d189c6aba6
parent6d2baf9dfbffe43019932c2771cd7d39697d4b11
OvmfPkg/OvmfPkgX64: Adjust load sequence of TdxDxe and AmdSevDxe driver

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3904

TdxDxe driver is introduced for Intel TDX feature. Unfortunately, this
driver also breaks boot process in SEV-ES guest. The root cause is in
the PciLib which is imported by TdxDxe driver.

In a SEV-ES guest the AmdSevDxe driver performs a
MemEncryptSevClearMmioPageEncMask() call against the
PcdPciExpressBaseAddress range to mark it shared/unencrypted. However,
the TdxDxe driver is loaded before the AmdSevDxe driver, and the PciLib
in TdxDxe is DxePciLibI440FxQ35 which will access the
PcdPciExpressBaseAddress range. Since the range has not been marked
shared/unencrypted, the #VC handler terminates the guest for trying to
do MMIO to an encrypted region.

Adjusting the load sequence of TdxDxe and AmdSevDxe can fix the issue.

Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
SEV-Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
TDX-Tested-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
OvmfPkg/OvmfPkgX64.fdf