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: [email protected]
Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
