Re: [PATCH V2 5/6] MdePkg: Probe Cc guest in BaseIoLibIntrinsicSev


Min Xu
 

On May 17, 2022 9:15 AM, Xu Min wrote:
On May 17, 2022 6:22 AM, dann frazier wrote:
I ran through our tests on stable-202205-rc1, and I'm finding that all
of the tests using 2M FD_SIZE & SMM_REQUIRE=TRUE are failing with
QEMU
hanging w/o output. Equivalent tests w/ 4M FD_SIZE are working fine. I
bisected it down to this commit, and also confirmed that reverting
this commit on top of 202205-rc1 also avoids the problem.

I might have a chance to debug more tomorrow, but for now I just
wanted to flag it.
This patch calls CcProbe () to get the Confidential Computing guest type.
There are 2 versions of CcProbeLib, one is to get the Cc guest type from
PcdOvmfWorkArea, the other is a null instance and it always return
CcGuestTypeNonEncrypted (which means it is a legacy vm guest). Only
OvmfPkgX64.dsc and IntelTdxX64.dsc include the first one (which probe the
PcdOvmfWorkArea).

If this patch is reverted, it means it is to check the guest type by calling CPUID,
not reading the PcdOvmfWorkArea.
More investigation shows that the root cause is the wrong memory access in SMM driver (PiSmmCpuDxeSmm.inf). This issue can be triggered when SMM_REQUIRE is TRUE.
IoLib is used in PiSmmCpuDxeSmm.inf. In OvmfPkgX64 BaseIoLibIntrinsicSev.inf is included and it probes if the working guest is td guest by CcProbe(). CcProbe reads PcdOvmfWorkArea (0x80B000) to get the guest type. It works in Non-SMM mode. But in SMM mode it is illegal. So reverting the patch makes the probe to call CPUID (0x21) instead of reading PcdOvmfWorkArea. It does work.

I am thinking how to fix this issue and then send out the patch-set for review.

Thanks
Min

Join devel@edk2.groups.io to automatically receive all group messages.