From: "Ni, Ray" <ray.ni@intel.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Wu, Jiaxin" <jiaxin.wu@intel.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"Zeng, Star" <star.zeng@intel.com>,
"Kumar, Rahul R" <rahul.r.kumar@intel.com>,
"Dong, Guo" <guo.dong@intel.com>,
"Rhodes, Sean" <sean@starlabs.systems>,
"Lu, James" <james.lu@intel.com>, "Guo, Gua" <gua.guo@intel.com>,
Ard Biesheuvel <ardb+tianocore@kernel.org>,
"Yao, Jiewen" <jiewen.yao@intel.com>,
Abdul Lateef Attar <AbdulLateef.Attar@amd.com>,
Abner Chang <abner.chang@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [edk2-devel] [PATCH v3 00/13] Add SmmRelocationLib
Date: Fri, 26 Apr 2024 06:07:16 +0000 [thread overview]
Message-ID: <MN6PR11MB82444A65F94A70A5EA06C4A48C162@MN6PR11MB8244.namprd11.prod.outlook.com> (raw)
In-Reply-To: <4fngcjpmyqnzyp6bh3ycylan2a3k4s4sy2tktankxor4eqnjth@txcoonsfhsmt>
[-- Attachment #1: Type: text/plain, Size: 3256 bytes --]
Thanks,
Ray
________________________________
From: Gerd Hoffmann <kraxel@redhat.com>
Sent: Thursday, April 25, 2024 14:58
To: Ni, Ray <ray.ni@intel.com>
Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Zeng, Star <star.zeng@intel.com>; Kumar, Rahul R <rahul.r.kumar@intel.com>; Dong, Guo <guo.dong@intel.com>; Rhodes, Sean <sean@starlabs.systems>; Lu, James <james.lu@intel.com>; Guo, Gua <gua.guo@intel.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>; Yao, Jiewen <jiewen.yao@intel.com>; Abdul Lateef Attar <AbdulLateef.Attar@amd.com>; Abner Chang <abner.chang@amd.com>; Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [edk2-devel] [PATCH v3 00/13] Add SmmRelocationLib
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.
[Ray] OK. that supports the OVMF instance's logic. But I'd like Tom or any other AMD guys to provide spec that says 0 for AMD32.
> 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?
[Ray] The CPU uses a fixed save state area layout no matter it runs in 32bit or 64bit.
The 64bit cpu only uses the 64bit format, no matter it runs in 32bit or 64bit.
So OvmfPkgIa32 builds could use the 32-bit format, OvmfPkgX64 builds use
the 64-bit format, everything works fine?
[Ray] For OVMF, it depends on how the virtual cpu is defined by QEMU implementation.
If the underline CPU is a AMD64 cpu, the CPU supports running in 32bit or 64bit modes. But no matter
it runs in 32bit or 64bit, the save state area layout always follows the 64bit format.
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 (#118310): https://edk2.groups.io/g/devel/message/118310
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]
-=-=-=-=-=-=-=-=-=-=-=-
[-- Attachment #2: Type: text/html, Size: 6039 bytes --]
next prev parent reply other threads:[~2024-04-26 6:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <17C74D78B0B952AD.15491@groups.io>
2024-04-18 8:02 ` [edk2-devel] [PATCH v3 00/13] Add SmmRelocationLib Wu, Jiaxin
2024-04-22 7:57 ` Gerd Hoffmann
2024-04-23 7:31 ` Wu, Jiaxin
2024-04-23 8:43 ` Gerd Hoffmann
2024-04-23 12:16 ` Wu, Jiaxin
2024-04-24 3:56 ` Wu, Jiaxin
2024-04-24 11:29 ` Gerd Hoffmann
2024-04-25 0:54 ` Wu, Jiaxin
2024-04-25 5:50 ` Ni, Ray
2024-04-25 6:58 ` Gerd Hoffmann
2024-04-26 6:07 ` Ni, Ray [this message]
2024-04-26 13:18 ` Lendacky, Thomas via groups.io
2024-04-18 8:03 ` Wu, Jiaxin
2024-04-19 3:35 ` Ni, Ray
2024-04-19 3:47 ` Chang, Abner via groups.io
2024-04-19 3:55 ` Wu, Jiaxin
2024-04-18 6:55 Wu, Jiaxin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MN6PR11MB82444A65F94A70A5EA06C4A48C162@MN6PR11MB8244.namprd11.prod.outlook.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox