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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#89804): https://edk2.groups.io/g/devel/message/89804 Mute This Topic: https://groups.io/mt/90477280/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
