2) Change ARCHITECTURAL_PROTOCOL_ENTRY name to EFI_CORE_PROTOCOL_NOTIFY_ENTRY so it can be used for both Architectural Protocols and optional protocols that the DXE Core may use. Also remove BOOLEAN ArchitecturalProtocol field, so it is back to its original form.
3) Put mArchProtocols[] back to its original form, but add a NULL entry at the end so the end of the table can be easily detected in loops
4) Add mOptionalProtocols[] that at this time only has the SMM Base 2 Protocol in it.
5) Add NULL entry to mMissingProtocols[] so the end of the table can be easily detected.
6) Update all loops on mArchProtocols[], mOptionalProtocols, and mMissingProtocols[] to remove Index(s) and simply looks for a NULL ProtocolGuid to find the end of the table.
7) Update protocol notify events to pass the associated EFI_CORE_PROTOCOL_NOTIFY_ENTRY * as the Context parameter. This simplifies GenericProtocolNotify() by completely eliminating the search loop.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10016 6f19259b-4bc3-4df7-8a09-765794883524
PI 1.2 SMM Drivers are allowed to call UEFI/DXE services and Protocols from the entry point of the PI 1.2 SMM Driver. These UEFI/DXE services and Protocols may directly or indirectly calls the UEFI Boot Services RaiseTPL() and RestoreTPL(). These UEFI Boot Services use the CPU Architectural Protocol to enable interrupts if the TPL level is below TPL_HIGH_LEVEL and enable interrupts of the TPL is at TPL_HIGH_LEVEL. Interrupts should be masked while executing SMM drivers, so if a direct or indirect call to the UEFI Boot Service RestoreTPL() would enable interrupts, then an interrupt could be incorrectly delivered in SMM context.
The solution is for the DXE Core to register for the PI 1.2 SMM Base2 Protocol. If that protocol is present in the platform, then the DXE Core can use the SMM Base 2 Protocol's InSmm() function to determine if the platform is currently executing in SMM content. If the current context is in SMM, then do not allow any requests to be forwarded to the CPU Architecture Protocol to enable interrupts.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9997 6f19259b-4bc3-4df7-8a09-765794883524
1) Remove references to CPU I/O PPI and PCI CFG2 PPI. The PEI Core does have the PEI Services Table that caches a copy of these, but the PEI Core never produces a real version of these PPIs. Instead, the PEI Core only has a null implementation of the APIs so we can catch PIEMs that call these services before they are properly installed.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9731 6f19259b-4bc3-4df7-8a09-765794883524
1. Rename EFI_PEI_NEXT_VARIABLE_NAME2 to EFI_PEI_GET_NEXT_VARIABLE_NAME2, as PI 1.2 specifies.
2. Add return status description for PEI Service FfsGetVolumeInfo.
3. Update parameter description for EFI_PEI_READ_ONLY_VARIABLE2_PPI.NextVariableName().
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9438 6f19259b-4bc3-4df7-8a09-765794883524
1, Implement EFI_PEI_FIRMWARE_VOLUME_PPI for FFS2 format as build-in supporting FV format in PeiCore.
2, Reduce the assumption of memory-mapped FV in PeiCore. PeiCore should access FV via EFI_PEI_FIRMWARE_VOLUME_PPI interface but not cast FvHandle/FileHandle to EFI_FIRMWARE_VOLUME_HEADER/EFI_FV_FILE_HEADER directly.
3, Reduce AllFv[] and AllFvCount in PEI_CORE_INSTANCE structure. Original PEI_CORE_INSTANCE use AllFv[] and Fv[] array to manage discovered FV and dispatched FV. But not need to make thing too complex. Now PEI_CORE_FV_HANDLE array of Fv[] will take responsibility to manage all FV instance and status.
4, Fix the bug use PeiDispatcher use wrong index for PeiFfsFindNextVolume(),
5, Fix the bug in PeiFfsFindNextVolume(), if instance is not found, *VolumeHandle should be set to NULL but not VolumeHandle was set to NULL.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9407 6f19259b-4bc3-4df7-8a09-765794883524
