> > 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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#99424): https://edk2.groups.io/g/devel/message/99424 Mute This Topic: https://groups.io/mt/96350764/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
