For simple, this change will keep compatibility with the lack of the HOB. When the HOB doesn't exist, PiSmmCpuDxeSmm driver will keep the original logic to program the new SMBASE in driver itself.
> -----Original Message----- > From: Wu, Jiaxin > Sent: Friday, January 13, 2023 6:19 PM > To: Gerd Hoffmann <kra...@redhat.com>; devel@edk2.groups.io > Subject: RE: [edk2-devel] [PATCH v1 0/4] Support SMM Relocated SmBase > handling > > Thanks Comments Gerd, I will resolve the CI check issue (I have noticed that > in https://github.com/tianocore/edk2/pull/3884) & refine the usage > description in next version. > > Anyway, Ray also helped explain the usage as below, I will integrate it in the > hob definition .h file, help below can help understand the design.: > > The default SMBASE for the x86 processor is 0x30000. When SMI happens, > CPU runs the > SMI handler at SMBASE+0x8000. Also, the SMM save state area is within > SMBASE+0x10000. > > One of the SMM initialization from CPU perspective is to program the new > SMBASE (in TSEG range) > for each CPU thread. When the SMBASE update happens in a PEI module, > the PEI module shall > produce the SMM_BASE_HOB in HOB database which tells the > PiSmmCpuDxeSmm driver which runs > at a later phase about the new SMBASE for each CPU thread. > PiSmmCpuDxeSmm driver installs > the SMI handler at the SMM_BASE_HOB.SmBase[Index]+0x8000 for CPU > thread Index. > When the HOB doesn't exist, PiSmmCpuDxeSmm driver shall program the > new SMBASE itself. > > I also explain the in the patch 2 for PiSmmCpuDxeSmm changes: > > SMM CPU driver will retrieve the SMBASE addresses from SMM Base Hob > and installs the SMI handler at [SMBASE+8000h] for each processor > instead of relocating SMM Base addresses from SMRAM again. > > With SMM Base Hob, SMM CPU driver does not need the RSM instruction > to reload the SMBASE register with the new allocated value in SMBASE > field each time it exits SMM. SMBASE Register for each processors > have already been programmed in parallel since the same default > SMBASE Address(0x30000) is not used, thus the CPUs over-writing > each other's SMM Save State Area will not happen. This way will save > boot time on multi-core system > > > thanks, > Jiaxin > > > > -----Original Message----- > > From: Gerd Hoffmann <kra...@redhat.com> > > Sent: Friday, January 13, 2023 5:50 PM > > To: devel@edk2.groups.io; Wu, Jiaxin <jiaxin...@intel.com> > > Subject: Re: [edk2-devel] [PATCH v1 0/4] Support SMM Relocated SmBase > > handling > > > > On Fri, Jan 13, 2023 at 03:17:34PM +0800, Wu, Jiaxin wrote: > > > Below serial patches are to support the SMM Relocated SmBase handling. > > > To achieve, new hob interface is procuded, and will be consumed by > SMM > > > CPU driver & SmmCpuFeaturesLib to do SmBase initialization: > > > > Who produces that HOB? I see only consumers in this patch series. > > > > The patch series doesn't even pass BaseTools/Scripts/PatchCheck.py, > > it will surely not pass CI. > > > > > With SMM Base Hob, SMM CPU driver does not need the RSM instruction > > > to reload the SMBASE register with the new allocated value in SMBASE > > > field each time it exits SMM. SMBASE Register for each processors > > > have already been programmed in parallel since the same default > > > SMBASE Address(0x30000) is not used, thus the CPUs over-writing > > > each other's SMM Save State Area will not happen. > > > > Care to explain how this works? SMBASE setup has to happen somewhere > > (probably in the HOB producer), how does that work without using the > > default smbase address? > > > > take care, > > Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#98470): https://edk2.groups.io/g/devel/message/98470 Mute This Topic: https://groups.io/mt/96241699/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
