From: "Wu, Jiaxin" <jiaxin.wu@intel.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Ni, Ray" <ray.ni@intel.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"Dong, Eric" <eric.dong@intel.com>,
"Zeng, Star" <star.zeng@intel.com>,
Laszlo Ersek <lersek@redhat.com>,
"Kumar, Rahul R" <rahul.r.kumar@intel.com>
Subject: Re: [PATCH v3 5/5] OvmfPkg/SmmCpuFeaturesLib: Skip SMBASE configuration
Date: Thu, 2 Feb 2023 01:41:38 +0000 [thread overview]
Message-ID: <MN0PR11MB61588FF985E6CC74808ECC90FED69@MN0PR11MB6158.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20230201134051.7jlc7a74cogcskw5@sirius.home.kraxel.org>
>
> Current state:
>
> * PiSmmCpuDxeSmm does SMM initialization, including programming
> SMBASE,
> serialized.
>
Yes.
> With this series applied:
>
> * Some PEI module programs SMBASE, serialized.
PEI module can also programs SMBASE in parallel. It depends on the implementation. both is fine.
> * PiSmmCpuDxeSmm does SMM initialization, but NOT programming SMBASE,
> in parallel.
>
Yes.
> Sure PiSmmCpuDxeSmm alone will run faster because it can run parallel
> now.
>
> But the serialized SMBASE programming still happens, now in the PEI
> module, and I don't see a good reason why the runtime the new PEI module
> and the runtime of PiSmmCpuDxeSmm combined is faster than before.
As I said, PEI module can also programs SMBASE in parallel, for example program the some register directly instead of depending the existing RSM instruction to reload the SMBASE register with the new allocated SMBASE each time when it exits SMM. Different vender might has different implementation. Another benefit with this series will make the smbase relocation more independent & more simple compared with existing process in smm cpu driver.
As you can see, this patch doesn't break existing code functionality& work flow, which means it's the compatible changes, which will bring the new approach for the pre-allocated smbase solution.
>
> > > * Where is the code?
> > See the design of existing function: SemaphoreHook (Index,
> &mRebased[Index]);
>
> I mean the PEI module code.
Gerd, different user (hob producer) might have different implementation for the pre-allocated smbase in the hob. It's flexible for the producer to implement the pre-allocated smbase and make sure it has take effect in the system. PEI module code is not in this series.
>
> > > * It is totally unclear whenever it is possible and/or useful to
> > > initialize SMM that way on OVMF.
>
> > Add the same handing logic code in OVMF is necessary to make sure it
> > work. If someone produced such hob in OVMF platform,
>
> Do you intent submitting code for OVMF producing such a HOB?
> There isn't any in this series.
No, we won't do that.
>
> > Changes in OVMF is make sure it runs into right way.
>
> As it stands you are only adding dead code for no reason.
>
I'm not looking for trouble for the OVMF part, as I also explained the OVMF patch:
This patch is to avoid configure SMBASE if SmBase relocation has been
done. If gSmmBaseHobGuid found, means SmBase info has been relocated
and recorded in the SmBase array. No need to do the relocation in
SmmCpuFeaturesInitializeProcessor().
Change the SmmCpuFeaturesLib in OVMF is also follow the Laszlo suggestion, and I also think it's the right way instead of adding dead code. Laszlo is the OVMF 'D' for ovmf part, I'm fine with the decision if we want to remove it (but I still hold the opinion keep it even no producer for OVMF).
> How is the SMM initialization of hotplugged CPUs
> supposed to work with the new mode of operation?
>
Yes, that's already considered. For hot plugged CPU supported, the max number of CPUs should be defined in the PcdCpuMaxLogicalProcessorNumber, and all CPU Hot Plug Data is recorded in the PcdCpuHotPlugDataAddress, which contains the smbase info pre-allocated in the hob (filling the value in pi smm cpu driver), then CPU Hotplug MMI handler will relocate the SMBASE for new CPUs.
> take care,
> Gerd
next prev parent reply other threads:[~2023-02-02 1:41 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-18 9:56 [PATCH v3 0/5] Simplify SMM Relocation Process Wu, Jiaxin
2023-01-18 9:56 ` [PATCH v3 1/5] UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB Data Wu, Jiaxin
2023-01-18 11:19 ` Gerd Hoffmann
2023-01-18 15:06 ` Ni, Ray
2023-01-19 7:13 ` Gerd Hoffmann
2023-01-29 5:08 ` Wu, Jiaxin
2023-02-01 13:02 ` Gerd Hoffmann
2023-01-20 8:21 ` Laszlo Ersek
2023-01-29 5:24 ` Wu, Jiaxin
2023-02-01 13:14 ` Gerd Hoffmann
2023-02-02 0:44 ` Wu, Jiaxin
2023-02-02 3:54 ` [edk2-devel] " Ni, Ray
2023-02-02 3:52 ` Ni, Ray
2023-02-02 12:51 ` Gerd Hoffmann
2023-02-02 22:29 ` [edk2-devel] " Brian J. Johnson
2023-02-03 3:14 ` Ni, Ray
2023-02-03 7:54 ` Gerd Hoffmann
2023-02-03 13:22 ` Wu, Jiaxin
2023-02-03 13:31 ` Ni, Ray
2023-02-03 15:00 ` Gerd Hoffmann
2023-01-18 9:56 ` [PATCH v3 2/5] UefiCpuPkg/PiSmmCpuDxeSmm: Fix invalid InitializeMpSyncData call Wu, Jiaxin
2023-01-18 9:56 ` [PATCH v3 3/5] UefiCpuPkg/PiSmmCpuDxeSmm: Consume SMM Base Hob for SmBase info Wu, Jiaxin
2023-01-18 12:02 ` Gerd Hoffmann
2023-01-29 6:14 ` [edk2-devel] " Wu, Jiaxin
2023-01-18 9:56 ` [PATCH v3 4/5] UefiCpuPkg/SmmCpuFeaturesLib: Skip SMBASE configuration Wu, Jiaxin
2023-01-18 9:56 ` [PATCH v3 5/5] OvmfPkg/SmmCpuFeaturesLib: " Wu, Jiaxin
2023-01-18 12:19 ` Gerd Hoffmann
2023-01-18 14:37 ` Ni, Ray
2023-01-19 7:53 ` Gerd Hoffmann
2023-01-29 5:47 ` Wu, Jiaxin
2023-02-01 13:40 ` Gerd Hoffmann
2023-02-02 1:41 ` Wu, Jiaxin [this message]
2023-02-02 9:00 ` Gerd Hoffmann
2023-02-02 11:47 ` Laszlo Ersek
2023-02-02 12:24 ` Gerd Hoffmann
2023-02-03 3:05 ` Wu, Jiaxin
2023-02-03 2:47 ` Wu, Jiaxin
2023-02-03 3:45 ` Ni, Ray
2023-02-03 7:31 ` Gerd Hoffmann
2023-02-03 7:43 ` Ni, Ray
2023-02-03 8:49 ` Gerd Hoffmann
2023-02-03 11:18 ` Wu, Jiaxin
[not found] ` <173B5EAF72B992BD.14781@groups.io>
2023-02-03 8:59 ` [edk2-devel] " Wu, Jiaxin
2023-02-03 9:04 ` Gerd Hoffmann
2023-02-03 11:15 ` 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=MN0PR11MB61588FF985E6CC74808ECC90FED69@MN0PR11MB6158.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