public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ni, Ray" <ray.ni@intel.com>
To: "Wu, Jiaxin" <jiaxin.wu@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "Zeng, Star" <star.zeng@intel.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"Kumar, Rahul R" <rahul.r.kumar@intel.com>
Subject: Re: [edk2-devel] [PATCH v2 02/10] UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib library instance
Date: Wed, 17 Apr 2024 05:24:34 +0000	[thread overview]
Message-ID: <MN6PR11MB8244EC302217C7999A8939A98C0F2@MN6PR11MB8244.namprd11.prod.outlook.com> (raw)
In-Reply-To: <MN0PR11MB6158537790B0FA4E52AF9F6AFE082@MN0PR11MB6158.namprd11.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 5691 bytes --]

Comments below starting with [Ray]

Thanks,
Ray

________________________________
From: Wu, Jiaxin <jiaxin.wu@intel.com>
Sent: Tuesday, April 16, 2024 20:58
To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io <devel@edk2.groups.io>
Cc: Zeng, Star <star.zeng@intel.com>; Gerd Hoffmann <kraxel@redhat.com>; Kumar, Rahul R <rahul.r.kumar@intel.com>
Subject: RE: [PATCH v2 02/10] UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib library instance



 /**
@@ -30,11 +30,12 @@ SemaphoreHook (
 {
   SMRAM_SAVE_STATE_MAP  *CpuState;

   mRebasedFlag = RebasedFlag;

-  CpuState                      = (SMRAM_SAVE_STATE_MAP *)(UINTN)(SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET);
+  CpuState = (SMRAM_SAVE_STATE_MAP *)(UINTN)(SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET);



[Ray.1] This change is unnecessary.

[Jiaxin.1] it’s not only move the code to the new lib, but also do some adaptation. For example here: the code style change to PASS the CI.

If no this change, can’t pass the CI check.

[Ray] Original code should also pass uncrustify checker. I guess you added one blank line above so the alignment of "=" is not required.




[Ray.4] Can you evaluate what extra changes are required if allowing the lib runs in flash area? Basically all global variables cannot be modified at runtime.

[Jiaxin.4] The Lib needs to depend on the MP service PPI, it shall be called during post-mem phase, global variables can’t be used?

[Ray] A PEIM could run in flash in post-mem phase. If you pass the values across routines through parameters, most of the global variables can be avoided.


+  UINTN                           SmramRanges;

[Ray.6] No need SmramRanges.

[Jiaxin.6] replace it with DescriptorBlock ->NumberOfSmmReservedRegions directly?

[Ray] yes.


+  //
+  // Increase the number of SMRAM descriptors by 1 to make room for the ALLOCATED descriptor of size EFI_PAGE_SIZE
+  //
+  NewDescriptorBlock->NumberOfSmmReservedRegions = (UINT32)(SmramRanges + 1);

[Ray.9] NewBlock->NumberOfSmmReservedRegions++;

[Jiaxin.9] Agree since we copied the DescriptorBlock to NewDescriptorBlock first. But I still think original is more easy to understand.

[Ray] As long as you remove local variable SmramRanges, I am fine.



+
+    DEBUG ((DEBUG_INFO, "CreateSmmBaseHob - SmmBaseHobData[%d]->ProcessorIndex: %03x\n", HobCount, SmmBaseHobData->ProcessorIndex));
+    DEBUG ((DEBUG_INFO, "CreateSmmBaseHob - SmmBaseHobData[%d]->NumberOfProcessors: %03x\n", HobCount, SmmBaseHobData->NumberOfProcessors));
+    for (Index = 0; Index < SmmBaseHobData->NumberOfProcessors; Index++) {
+      //
+      // Calculate the new SMBASE address
+      //
+      SmmBaseHobData->SmBase[Index] = SmBaseForAllCpus[Index + CpuCount];

[Ray.12] Please re-organize the code so that SmBaseForAllCpus array is not needed. What we need is only the Cpu0SmBase and TileSize.

[Jiaxin.12] do you mean calculate the value here? --> (UINTN)(Cpu0SmBase)+ Index * TileSize - SMM_HANDLER_OFFSET ?

I init the smbase value in the function of InitSmBaseForAllCpus(), the value will be used in both ConfigureSmBase & CreateSmmBaseHob.

How about the ConfigureSmBase function during SmmRelocateBases()? What’s reason you think SmBaseForAllCpus is not good?

[Ray] I just want to avoid unnecessary memory allocation.




+
+  //
+  // Patch SMI stack for SMM base relocation
+  // Note: No need allocate stack for all CPUs since the relocation
+  // occurs serially for each CPU
+  //
+  SmmStackSize = EFI_PAGES_TO_SIZE (EFI_SIZE_TO_PAGES (PcdGet32 (PcdCpuSmmStackSize)));

[Ray.15] PcdCpuSmmStackSize is configured by platform as only platform knows what kind of SMI handlers will run in SMM env.

But in this case, all code is provided by this lib and stack size should be fixed, maybe simply 1 page is enough.

[Jiaxin.15] agree, do you prefer this change as another patch or I just update the hard code value directly in this patch?

[Ray] If the code is inherited from PiSmmCpuDxeSmm driver, you can do that change in another patch.

+  //
+  // Retrieve the Processor Info for all CPUs
+  //
+  mProcessorInfo = (EFI_PROCESSOR_INFORMATION *)AllocatePool (sizeof (EFI_PROCESSOR_INFORMATION) * mMaxNumberOfCpus);

[Ray.16] mProcessorInfo is needed when programming the new SMBASE. Then can you just put the new SMBASE for every CPU in the stack top, or just patch the value in the code region?

You can do that in a new patch.

[Jiaxin.16] why need such behavior? I only allocate one stack for all cpus with existing design. The reason see below as I explained:

[Ray] My purpose is to avoid global variables.



+  //
+  // Initialize the SmBase for all CPUs
+  //
+  Status = InitSmBaseForAllCpus (&mSmBaseForAllCpus);

[Ray.17] mSmBaseForAllCpus global variable is not needed. We only need Cpu0Smbase and TileSize and the two can be local variables and passed to further routines through parameters.

[Jiaxin.17] let me remove the mSmBaseForAllCpus global variable. But I still think it’s not good to calculate value in different 2 places again and again (ConfigureSmBase & CreateSmmBaseHob).

[Ray] I agree with you regarding not calculating values in more than 1 place. Please think about how to avoid that.





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117893): https://edk2.groups.io/g/devel/message/117893
Mute This Topic: https://groups.io/mt/105535806/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: 16138 bytes --]

  reply	other threads:[~2024-04-17  5:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-15 13:30 [edk2-devel] [PATCH v2 00/10] Add SmmRelocationLib Wu, Jiaxin
2024-04-15 13:30 ` [edk2-devel] [PATCH v2 01/10] UefiCpuPkg: Add SmmRelocationLib class Wu, Jiaxin
2024-04-16  1:50   ` Ni, Ray
2024-04-15 13:30 ` [edk2-devel] [PATCH v2 02/10] UefiCpuPkg/SmmRelocationLib: Add SmmRelocationLib library instance Wu, Jiaxin
2024-04-16  3:19   ` Ni, Ray
2024-04-16 12:58     ` Wu, Jiaxin
2024-04-17  5:24       ` Ni, Ray [this message]
2024-04-15 13:30 ` [edk2-devel] [PATCH v2 03/10] UefiCpuPkg/SmmRelocationLib: Add library instance for AMD Wu, Jiaxin
2024-04-16  3:27   ` Ni, Ray
2024-04-15 13:30 ` [edk2-devel] [PATCH v2 04/10] OvmfPkg/SmmRelocationLib: Add library instance for OVMF Wu, Jiaxin
2024-04-15 13:30 ` [edk2-devel] [PATCH v2 05/10] OvmfPkg/PlatformInitLib: Create gEfiSmmSmramMemoryGuid Wu, Jiaxin
2024-04-15 13:30 ` [edk2-devel] [PATCH v2 06/10] OvmfPkg: Refine SmmAccess implementation Wu, Jiaxin
2024-04-15 13:30 ` [edk2-devel] [PATCH v2 07/10] OvmfPkg/SmmCpuFeaturesLib: Check Smbase Relocation is done or not Wu, Jiaxin
2024-04-15 13:30 ` [edk2-devel] [PATCH v2 08/10] OvmfPkg/PlatformPei: Relocate SmBases in PEI phase Wu, Jiaxin
2024-04-15 13:30 ` [edk2-devel] [PATCH v2 09/10] UefiPayloadPkg/UefiPayloadPkg.dsc: Include SmmRelocationLib Wu, Jiaxin
2024-04-15 15:26   ` Guo Dong
2024-04-15 13:30 ` [edk2-devel] [PATCH v2 10/10] UefiCpuPkg/PiSmmCpuDxeSmm: Remove SmBases relocation logic Wu, Jiaxin
2024-04-16  7:31 ` [edk2-devel] [PATCH v2 00/10] Add SmmRelocationLib Gerd Hoffmann
2024-04-16 10:08   ` 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=MN6PR11MB8244EC302217C7999A8939A98C0F2@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