Re: [edk2-devel] [PATCH v3 00/13] Add SmmRelocationLib

["Gerd Hoffmann" <kraxel@redhat.com>]

  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/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-