Hi, > That means the SMMRevId is 0_xx64h for AMD64 processor. But I am not > sure what the value is for AMD32 processor. Maybe 0 according to the > OVMF logic.
The smm emulation in the linux kernel uses 0 and 0x64. > But, I am very suspicious about the logic in AMD's version as below: > --- AMD's version > SmmSaveStateRegisterLma = (UINT8)EFI_MM_SAVE_STATE_REGISTER_LMA_32BIT; > > LMAValue = (UINT32)AsmReadMsr64 (EFER_ADDRESS) & LMA; > if (LMAValue) { > SmmSaveStateRegisterLma = (UINT8)EFI_MM_SAVE_STATE_REGISTER_LMA_64BIT; > } > --- > The above logic detects the current CPU mode and 64bit save state area layout > is used if it's running in 64bit. > But if a AMD64 CPU runs in 32bit mode, the above logic causes the > 32bit save state area layout is used. It's not right! The save state > area layout does not depend on the CPU running mode, but whether it's > a legacy CPU or a 64-capable CPU. Well, that is not entirely clear to me. Could it be 64-bit processors support both 32-bit and 64-bit format, for backward compatibility reasons? So OvmfPkgIa32 builds could use the 32-bit format, OvmfPkgX64 builds use the 64-bit format, everything works fine? The tricky corner case is OvmfPkgIa32X64, where (after applying this series) 32-bit PEI should setup things for 64-bit SMM/DXE, and checking the current processor mode will not give use the result we need. > Jiaxin, I agree that the confusion should be cleaned up by AMD > experts. Let's not change any existing behavior. Agree. Tom? take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#118272): https://edk2.groups.io/g/devel/message/118272 Mute This Topic: https://groups.io/mt/105593568/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-