summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-12-03IntelFrameworkModulePkg: remove unreachable codeArd Biesheuvel
Some compilers (like RVCT) are finicky about unreachable code, so remove it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19105 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-03BaseTools PatchCheck.py: Support binary diffJordan Justen
This allows a patch with binary data that is generated with --binary to be parsed by the PatchCheck.py script. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19104 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-03BaseTools: Add VS2015 tool chain in tools_def.templateWang Yu
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wang Yu <yu.wang@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19101 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-03UefiCpuPkg/CpuS3DataDxe: Add more detailed description on GUID in INFJeff Fan
Add the GUID gEfiEndOfDxeEventGroupGuid usage description in more details in INF file. Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19100 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-02EmulatorPkg: Fix GCC49 build hang in PeiCoreJordan Justen
This is a port of 55e96f9c601781b8dc52c40747922f6ca3521f9e / r17902 to EmulatorPkg: commit 55e96f9c601781b8dc52c40747922f6ca3521f9e Author: Ruiyu Ni <ruiyu.ni@intel.com> Date: Thu Jul 9 08:55:23 2015 +0000 OvmfPkg: Fix GCC49 build hang in PeiCore Cc: Andrew Fish <afish@apple.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Fixes: https://github.com/tianocore/edk2/issues/24 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19099 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-02ArmPkg RVCT: add asm macro combining EXPORT, AREA and label definitionEugene Cohen
In response to Leif's request earlier, this adds a new RVCT assembler macro to centralize the exporting of assembly functions including the EXPORT directive (so the linker can see it), the AREA directive (so it's in its own section for code size reasons) and the function label itself. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen <eugene@hp.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19098 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-02BaseTools RVCT: add preprocessor preinclude for AutoGen.hEugene Cohen
Ensure that AutoGen.h is force-included when the RVCT preprocessor is invoked. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen <eugene@hp.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19097 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-02UefiCpuPkg/CpuMpPei: Fix typo and add some commentsJeff Fan
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19090 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-02UefiCpuPkg/CpuMpPei: Save/Restore CRx/DRx register for APs waking upJeff Fan
PeiStartupAllAPs()/PeiStartupThisAP() will send INIT-SIPI-SIPI to wakeup APs to execute AP function. However, some registers will be reset after APs received INIT IPI. We need to restore some registers (For example, CRx/DRx) manually after APs wakeup. Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19089 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-02UefiCpuPkg/CpuMpPei: Sync BSP's CRx to APs when initializationJeff Fan
Save BSP's volatile register and sync CRx register to APs when AP 1st wake up. Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19088 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-02UefiCpuPkg/CpuMpPei: Set AP state to CpuStateIdle after initializationJeff Fan
Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19087 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-02UefiCpuPkg/CpuMpPei: Add CPU_VOLATILE_REGISTERS & worker functionsJeff Fan
Add CPU_VOLATILE_REGISTERS definitions for CRx and DRx required to be restored after APs received INIT IPI. Add worker functions SaveVolatileRegisters()/RestoreVolatileRegisters() used to save/restore CRx and DRx. It also check if Debugging Extensions supported or not. Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19086 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-02UefiCpuPkg/CpuMpPei: Exchange whole CPU data in SortApicId()Jeff Fan
Current implementation only exchanges the APIC ID and BIST, this updating is to exchange all CPU data. Cc: Feng Tian <feng.tian@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@Intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19085 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-01ArmPkg: Convert whole-cache InvalidateInstructionCache to just ASSERTEugene Cohen
In SVN 18756 ("disallow whole D-cache maintenance operations") InvalidateInstructionCache was modified to remove the full data cache clean but left the full instruction cache invalidate. The change was made to address issues in the set/way clean methodology but the resulting code could lead someone to a painful debug. If a component called this function, the proper code would not be flushed to the PoU, since the intent of this function is not only to invalidate the I-cache but to provide coherency after code loading / modification. This change simply places an ASSERT(FALSE) in this function to avoid this hazard. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen <eugene@hp.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19084 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-01MdeModulePkg/BootLogoLib: Fix INF comments to follow coding standardsRuiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Shumin Qiu <shumin.qiu@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19083 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-01MdeModulePkg/BmpImageDecoderLib: Fix function header commentsRuiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Shumin Qiu <shumin.qiu@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19082 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-01BaseTools: Clean some coding style issuesYonghong Zhu
This patch clean some coding style issues, majorly for space character. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19080 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-01MdeModulePkg/NvmExpressDxe: Fix wrong logic in GetControllerName()Anbazhagan, Baraneedharan
NvmExpressComponentNameGetControllerName returns EFI_UNSUPPORTED if child handle is passed. gEfiNvmExpressPassThruProtocolGuid needs to be passed to EfiTestChildHandle instead of gEfiPciIoProtocolGuid. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: "Anbazhagan, Baraneedharan" <anbazhagan@hp.com> Reviewed-by: "Tian, Feng" <feng.tian@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19071 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: replace README fine print about X64 SMM S3 with PlatformPei checkLaszlo Ersek
At the moment, the "UefiCpuPkg/Universal/Acpi/S3Resume2Pei" module doesn't support S3 resume if the platform has SMM enabled and the PEI phase is built for X64. We document this in the README, but it is not conspicuous enough. Replace the "fine print" in the README with a runtime check in PlatformPei. Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19070 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30CorebootPayloadPkg PlatformHookLib: Fix GCC build failureStar Zeng
Add return status check to fix GCC build failure below. error: right-hand operand of comma expression has no effect [-Werror=unused-value] ((_gPcd_BinaryPatch_PcdSerialUseMmio = (Value)), RETURN_SUCCESS) error: right-hand operand of comma expression has no effect [-Werror=unused-value] ((_gPcd_BinaryPatch_PcdSerialRegisterBase = (Value)), RETURN_SUCCESS) http://article.gmane.org/gmane.comp.bios.edk2.devel/4949 Cc: Maurice Ma <maurice.ma@intel.com> Cc: Prince Agyeman <prince.agyeman@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Maurice Ma <maurice.ma@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19069 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30UefiCpuPkg/PiSmmCpu: Always set WP in CR0Yao, Jiewen
So that we can use write-protection for code later. It is REPOST. It includes suggestion from Michael Kinney <michael.d.kinney@intel.com>: - "For IA32 assembly, can we combine into a single OR instruction that sets both page enable and WP?" - "For X64, does it make sense to use single OR instruction instead of 2 BTS instructions as well?" Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com> Suggested-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Cc: "Fan, Jeff" <jeff.fan@intel.com> Cc: "Kinney, Michael D" <michael.d.kinney@intel.com> Cc: "Laszlo Ersek" <lersek@redhat.com> Cc: "Paolo Bonzini" <pbonzini@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19068 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30UefiCpuPkg/PiSmmCpu: Always set RW+P bit for page table by defaultYao, Jiewen
So that we can use write-protection for code later. This is REPOST. It includes the bug fix from "Paolo Bonzini" <pbonzini@redhat.com>: Title: fix generation of 32-bit PAE page tables "Bits 1 and 2 are reserved in 32-bit PAE Page Directory Pointer Table Entries (PDPTEs); see Table 4-8 in the SDM. With VMX extended page tables, the processor notices and fails the VM entry as soon as CR0.PG is set to 1." And thanks "Laszlo Ersek" <lersek@redhat.com> to validate the fix. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com> Signed-off-by: "Paolo Bonzini" <pbonzini@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Cc: "Fan, Jeff" <jeff.fan@intel.com> Cc: "Kinney, Michael D" <michael.d.kinney@intel.com> Cc: "Laszlo Ersek" <lersek@redhat.com> Cc: "Paolo Bonzini" <pbonzini@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19067 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: README: document SMM statusLaszlo Ersek
Cc: Paolo Bonzini <pbonzini@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19066 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: pull in SMM-based variable driver stackLaszlo Ersek
When -D SMM_REQUIRE is given, replace both - OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf and - OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf with - OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf. The outermost (= runtime DXE driver) VariableSmmRuntimeDxe enters SMM, and the rest: - the privileged half of the variable driver, VariableSmm, - the fault tolerant write driver, FaultTolerantWriteSmm, - and the FVB driver, FvbServicesSmm, work in SMM purely. We also resolve the BaseCryptLib class for DXE_SMM_DRIVER modules, for the authenticated VariableSmm driver's sake. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19065 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: consolidate variable driver stack in DSC and FDF filesLaszlo Ersek
The following modules constitute the variable driver stack: - QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, runtime alternatives for providing the Firmware Volume Block(2) Protocol, dependent on qemu pflash presence, - FaultTolerantWriteDxe, providing the Fault Tolerant Write Protocol, - MdeModulePkg/Universal/Variable/RuntimeDxe, independently of -D SECURE_BOOT_ENABLE, providing the Variable and Variable Write Architectural Protocols. Let's move these drivers closer to each other in the DSC and FDF files, so that we can switch the variable driver stack to SMM with more local changes. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19064 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: QemuFlashFvbServicesRuntimeDxe: adhere to -D SMM_REQUIRELaszlo Ersek
When the user requires "security" by passing -D SMM_REQUIRE, and consequently by setting PcdSmmSmramRequire, enforce flash-based variables. Furthermore, add two ASSERT()s to catch if the wrong module were pulled into the build. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19063 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: QemuFlashFvbServicesRuntimeDxe: add DXE_SMM_DRIVER buildLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19062 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: build PiSmmCpuDxeSmm for -D SMM_REQUIRELaszlo Ersek
At this point we can enable building PiSmmCpuDxeSmm. CPU specific features, like SMRR detection, and functions that are used to initialize SMM and process SMIs, are abstracted through the SmmCpuFeaturesLib class for the PiSmmCpuDxeSmm module. Resolve it to our own implementation under OvmfPkg -- it allows PiSmmCpuDxeSmm to work with QEMU's and KVM's 64-bit state save map format, which follows the definition from AMD's programmer manual. SmmCpuPlatformHookLib provides platform specific functions that are used to initialize SMM and process SMIs. Resolve it to the one Null instance provided by UefiCpuPkg, which is expected to work for most platforms. Cc: Paolo Bonzini <pbonzini@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> [pbonzini@redhat.com: resolve the SmmCpuFeaturesLib class to OVMF's own instance] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19061 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: build CpuS3DataDxe for -D SMM_REQUIRELaszlo Ersek
The PiSmmCpuDxeSmm driver from UefiCpuPkg depends on the ACPI_CPU_DATA structure -- created by a platform- and CPU-specific driver -- in order to support ACPI S3. The address of this structure is communicated through the dynamic PCD PcdCpuS3DataAddress. The "UefiCpuPkg/Include/AcpiCpuData.h" header file documents the fields of this structure in detail. The simple/generic "UefiCpuPkg/CpuS3DataDxe" driver creates and populates the structure in a conformant way, and it co-operates well with PiSmmCpuDxeSmm, for OVMF's purposes. PlatformBdsLib CpuS3DataDxe PiSmmCpuDxeSmm S3Resume2Pei (DXE_DRIVER) (DXE_DRIVER) (DXE_SMM_DRIVER) (PEIM) -------------- --------------- ---------------- -------------- normal collects data boot except MTRR settings into ACPI_CPU_DATA sets PcdCpuS3Da... signals End-of-Dxe | +----------> collects MTRR settings into ACPI_CPU_DATA installs [Dxe]Smm ReadyToLock | +---------------------------> fetches PcdCpuS3Dat... copies ACPI_CPU_DATA into SMRAM runtime S3 suspend S3 transfers resume control to PiSmmCpuDxe... | uses <----+ ACPI_CPU_DATA from SMRAM Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19060 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: any AP in SMM should not wait for the BSP for more than 100 msLaszlo Ersek
This patch complements the previous one, "OvmfPkg: use relaxed AP SMM synchronization mode". While that patch focuses on the case when the SMI is raised synchronously by the BSP, on the BSP: BSPHandler() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c] SmmWaitForApArrival() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c] IsSyncTimerTimeout() [UefiCpuPkg/PiSmmCpuDxeSmm/SyncTimer.c] this patch concerns itself with the case when it is one of the APs that raises (and sees delivered) the synchronous SMI: APHandler() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c] IsSyncTimerTimeout() [UefiCpuPkg/PiSmmCpuDxeSmm/SyncTimer.c] Namely, in APHandler() the AP waits for the BSP to enter SMM regardless of PcdCpuSmmSyncMode, for PcdCpuSmmApSyncTimeout microseconds (the default value is 1 second). If the BSP doesn't show up in SMM within that interval, then the AP brings it in with a directed SMI, and waits for the BSP again for PcdCpuSmmApSyncTimeout microseconds. Although during boot services, SmmControl2DxeTrigger() is only called by the BSP, at runtime the OS can invoke runtime services from an AP (it can even be forced with "taskset -c 1 efibootmgr"). Because on QEMU SmmControl2DxeTrigger() only raises the SMI for the calling processor (BSP and AP alike), the first interval above times out invariably in such cases -- the BSP never shows up before the AP calls it in. In order to mitigate the performance penalty, decrease PcdCpuSmmApSyncTimeout to one tenth of its default value: 100 ms. (For comparison, Vlv2TbltDevicePkg sets 1 ms.) NOTE: once QEMU becomes capable of synchronous broadcast SMIs, this patch and the previous one ("OvmfPkg: use relaxed AP SMM synchronization mode") should be reverted, and SmmControl2DxeTrigger() should be adjusted instead. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19059 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: use relaxed AP SMM synchronization modePaolo Bonzini
Port 0xb2 on QEMU only sends an SMI to the currently executing processor. The SMI handler, however, and in particular SmmWaitForApArrival, currently expects that SmmControl2DxeTrigger triggers an SMI IPI on all processors rather than just the BSP. Thus all SMM invocations loop for a second (the default value of PcdCpuSmmApSyncTimeout) before SmmWaitForApArrival sends another SMI IPI to the APs. With the default SmmCpuFeaturesLib, 32-bit machines must broadcast SMIs because 32-bit machines must reset the MTRRs on each entry to system management modes (they have no SMRRs). However, our virtual platform does not have problems with cacheability of SMRAM, so we can use "directed" SMIs instead. To do this, just set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode to 1 (aka SmmCpuSyncModeRelaxedAp). This fixes SMM on multiprocessor virtual machines. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19058 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: SmmCpuFeaturesLib: customize state save map formatPaolo Bonzini
This adjusts the previously introduced state save map access functions, to account for QEMU and KVM's 64-bit state save map following the AMD spec rather than the Intel one. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [lersek@redhat.com: reflow commit message, convert patch to CRLF] Cc: Paolo Bonzini <pbonzini@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19057 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: SmmCpuFeaturesLib: implement SMRAM state save map accessPaolo Bonzini
This implementation copies SMRAM state save map access from the PiSmmCpuDxeSmm module. The most notable change is: - dropping support for EFI_SMM_SAVE_STATE_REGISTER_IO - changing the implementation of EFI_SMM_SAVE_STATE_REGISTER_LMA to use the SMM revision id instead of a local variable (which UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c initializes from CPUID's LM bit). This accounts for QEMU's implementation of x86_64, which always uses revision 0x20064 even if the LM bit is zero. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [lersek@redhat.com: reflow commit message & fix typo, convert patch to CRLF] Cc: Paolo Bonzini <pbonzini@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19056 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: SmmCpuFeaturesLib: remove unnecessary bitsPaolo Bonzini
SMRR, MTRR, and SMM Feature Control support is not needed on a virtual platform. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: insert space between ASSERT and (), convert to CRLF, refresh against SVN r18958] Cc: Paolo Bonzini <pbonzini@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19055 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: import SmmCpuFeaturesLib from UefiCpuPkgPaolo Bonzini
The next patches will customize the implementation, but let's start from the common version to better show the changes. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [lersek@redhat.com: drop UNI file, keep whitespace intact, generate new FILE_GUID, split off DSC changes, reflow commit message, refresh against SVN r18958] Cc: Paolo Bonzini <pbonzini@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19054 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection to FALSELaszlo Ersek
Explanation from Michael Kinney: This PCD allows a platform to provide PlatformSmmBspElection() in a platform specific SmmCpuPlatformHookLib instance to decide which CPU gets elected to be the BSP in each SMI. The SmmCpuPlatformHookLibNull [instance] always returns EFI_NOT_READY for that function, which makes the module behave the same as the PCD being set to FALSE. The default is TRUE, so the platform lib is always called, so a platform developer can implement the hook function and does not have to also change a PCD setting for the hook function to be active. A platform that wants to eliminate the call to the hook function [altogether] can set the PCD to FALSE. So for OVMF, I think it makes sense to set this PCD to FALSE in the DSC file. Suggested-by: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19053 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: select LocalApicLib instance with x2apic supportLaszlo Ersek
Although neither LocalApicLib instance is suitable for runtime DXE drivers (because they access the APIC at the physical address retrieved from either MSR_IA32_APIC_BASE_ADDRESS or PcdCpuLocalApicBaseAddress), they are suitable for SMM drivers -- SMM drivers are not influenced by the runtime OS's virtual address map. PiSmmCpuDxeSmm links against LocalApicLib. 64-bit Linux guests tend to enable x2apic mode even in simple VCPU configurations (e.g., 4 sockets, 1 core/socket, 1 thread/core): [ 0.028173] x2apic enabled If PiSmmCpuDxeSmm was linked with the BaseXApicLib instance (i.e., with no x2apic support), then the next runtime service call that is backed by an SMM driver triggers the following ASSERT in BaseXApicLib (because the latter notices that x2apic has been enabled, which it doesn't support): ASSERT .../UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c(263): ApicBaseMsr.Bits.Extd == 0 It is reasonable to give all LocalApicLib client modules in OVMF the same level of x2apic support, hence resolve LocalApicLib globally to BaseXApicX2ApicLib. This will not be conditional on -D SMM_REQUIRE, because BaseXApicX2ApicLib is compatible with BaseXApicLib in any environment where the latter can be used. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19052 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: resolve DebugAgentLib for DXE_SMM_DRIVER modulesMichael Kinney
Add mappings to DebugAgentLib for SMM modules to prevent build breaks when SMM_REQUIRE and SOURCE_DEBUG_ENABLE are both set. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> [lersek@redhat.com: cover the X64 dsc, update commit msg, kudos Jordan] Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19051 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: resolve CpuExceptionHandlerLib for DXE_SMM_DRIVER modulesLaszlo Ersek
UefiCpuPkg/PiSmmCpuDxeSmm depends on this library (the RegisterCpuInterruptHandler() function specifically) to set up its specialized page fault handler (SmiPFHandler() -> DumpModuleInfoByIp()). It doesn't hurt to resolve this library class for all DXE_SMM_DRIVER modules. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19050 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: resolve ReportStatusCodeLib for DXE_SMM_DRIVER modulesLaszlo Ersek
PiSmmCpuDxeSmm depends on this library class, and it's okay to resolve it generally for all DXE_SMM_DRIVER modules. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19049 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRELaszlo Ersek
During DXE, drivers save data in the LockBox. A save operation is layered as follows: - The unprivileged driver wishing to store data in the LockBox links against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf" library instance. The library allows the unprivileged driver to format requests for the privileged SMM LockBox driver (see below), and to parse responses. We apply this resolution for DXE_DRIVER modules. - The privileged SMM LockBox driver is built from "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver has module type DXE_SMM_DRIVER and can access SMRAM. The driver delegates command parsing and response formatting to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf". Therefore we include this DXE_SMM_DRIVER in the build, and apply said resolution specifically to it. (Including the driver requires us to resolve a few of other library classes for DXE_SMM_DRIVER modules.) - In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei) retrieves data from the LockBox. It is capable of searching SMRAM itself. We resolve LockBoxLib to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically for this one PEIM. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19048 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: PlatformPei: don't allocate fake lockbox if SMM_REQUIRELaszlo Ersek
Since our fake LockBox must not be selected with -D SMM_REQUIRE (see the previous patch), it makes sense to set aside memory for it only if -D SMM_REQUIRE is absent. Modify InitializeRamRegions() accordingly. This patch completes the -D SMM_REQUIRE-related tweaking of the special OVMF memory areas. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19047 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: LockBoxLib: -D SMM_REQUIRE excludes our fake lockboxLaszlo Ersek
When the user builds OVMF with -D SMM_REQUIRE, our LockBox implementation must not be used, since it doesn't actually protect data in the LockBox from the runtime guest OS. Add an according assert to LockBoxLibInitialize(). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19046 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: AcpiS3SaveDxe: don't fake LockBox protocol if SMM_REQUIRELaszlo Ersek
In SVN r15306 (git commit d4ba06df), "OvmfPkg: S3 Resume: fake LockBox protocol for BootScriptExecutorDxe", we installed a fake LockBox protocol in OVMF's AcpiS3SaveDxe clone. While our other AcpiS3SaveDxe customizations remain valid (or harmless), said change is invalid when OVMF is built with -D SMM_REQUIRE and includes the real protocol provider, "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19045 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: pull in CpuIo2Smm driverLaszlo Ersek
This driver provides EFI_SMM_CPU_IO2_PROTOCOL, which the SMM core depends on in its gEfiDxeSmmReadyToLockProtocolGuid callback (SmmReadyToLockHandler(), "MdeModulePkg/Core/PiSmmCore/PiSmmCore.c"). Approached on a higher level, this driver provides the SmmIo member of the EFI_SMM_SYSTEM_TABLE2 (SMST). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19044 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: pull in the SMM IPL and SMM coreLaszlo Ersek
"MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf" (a DXE_RUNTIME_DRIVER) implements the SMM Initial Program Loader. It produces EFI_SMM_BASE2_PROTOCOL and EFI_SMM_COMMUNICATION_PROTOCOL, relying on: - EFI_SMM_ACCESS2_PROTOCOL (provided by OvmfPkg/SmmAccess/SmmAccess2Dxe.inf), - EFI_SMM_CONTROL2_PROTOCOL (provided by OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf). (The SMM IPL also depends on EFI_SMM_CONFIGURATION_PROTOCOL_GUID, but this dependency is not enforced in the entry point. A protocol notify callback is registered instead, hence we can delay providing that protocol via the PiSmmCpuDxeSmm driver that is (to be) imported from UefiCpuPkg/.) The SMM IPL loads the SMM core into SMRAM and executes it from there. Therefore we add the SMM core to the build as well. For the SMM core, a number of library classes need to be resolved. Furthermore, each FDF file must provide the GenFds.py BaseTools utility with a build rule for SMM_CORE; we copy the DXE_CORE's rule. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19043 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVERLaszlo Ersek
The EFI_SMM_COMMUNICATION_PROTOCOL implementation that is provided by the SMM core depends on EFI_SMM_CONTROL2_PROTOCOL; see the mSmmControl2->Trigger() call in the SmmCommunicationCommunicate() function [MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c]. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19042 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: add DXE_DRIVER for providing TSEG-as-SMRAM during boot-time DXELaszlo Ersek
The SMM core depends on EFI_SMM_ACCESS2_PROTOCOL. This small driver (which is a thin wrapper around "OvmfPkg/SmmAccess/SmramInternal.c" that was added in the previous patch) provides that protocol. Notably, EFI_SMM_ACCESS2_PROTOCOL is for boot time only, therefore our MODULE_TYPE is not DXE_RUNTIME_DRIVER. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19041 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEILaszlo Ersek
"MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the LockBoxLib instance with SMRAM access for the PEI phase. Said library instance must, and can, access the LockBox data in SMRAM directly if it is invoked before SMBASE relocation / SMI handler installation. In that case, it only needs PEI_SMM_ACCESS_PPI from the platform, and it doesn't depend on EFI_PEI_SMM_COMMUNICATION_PPI. OVMF satisfies the description in SVN r18823 ("MdeModulePkg: SmmLockBoxPeiLib: work without EFI_PEI_SMM_COMMUNICATION_PPI"): in OVMF, only S3Resume2Pei links against SmmLockBoxPeiLib. Therefore, introduce a PEIM that produces the PEI_SMM_ACCESS_PPI interface, enabling SmmLockBoxPeiLib to work; we can omit including "UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf". The load / installation order of S3Resume2Pei and SmmAccessPei is indifferent. SmmAccessPei produces the gEfiAcpiVariableGuid HOB during its installation (which happens during PEI), but S3Resume2Pei accesses the HOB only when the DXE IPL calls its S3RestoreConfig2 PPI member, as last act of PEI. MCH_SMRAM_D_LCK and MCH_ESMRAMC_T_EN are masked out the way they are, in SmmAccessPeiEntryPoint() and SmramAccessOpen() respectively, in order to prevent VS20xx from warning about the (otherwise fully intentional) truncation in the UINT8 casts. (Warnings reported by Michael Kinney.) Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19040 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire setLaszlo Ersek
PlatformPei calls GetSystemMemorySizeBelow4gb() in three locations: - PublishPeiMemory(): on normal boot, the permanent PEI RAM is installed so that it ends with the RAM below 4GB, - QemuInitializeRam(): on normal boot, memory resource descriptor HOBs are created for the RAM below 4GB; plus MTRR attributes are set (independently of S3 vs. normal boot) - MemMapInitialization(): an MMIO resource descriptor HOB is created for PCI resource allocation, on normal boot, starting at max(RAM below 4GB, 2GB). The first two of these is adjusted for the configured TSEG size, if PcdSmmSmramRequire is set: - In PublishPeiMemory(), the permanent PEI RAM is kept under TSEG. - In QemuInitializeRam(), we must keep the DXE out of TSEG. One idea would be to simply trim the [1MB .. LowerMemorySize] memory resource descriptor HOB, leaving a hole for TSEG in the memory space map. The SMM IPL will however want to massage the caching attributes of the SMRAM range that it loads the SMM core into, with gDS->SetMemorySpaceAttributes(), and that won't work on a hole. So, instead of trimming this range, split the TSEG area off, and report it as a cacheable reserved memory resource. Finally, since reserved memory can be allocated too, pre-allocate TSEG in InitializeRamRegions(), after QemuInitializeRam() returns. (Note that this step alone does not suffice without the resource descriptor HOB trickery: if we omit that, then the DXE IPL PEIM fails to load and start the DXE core.) - In MemMapInitialization(), the start of the PCI MMIO range is not affected. We choose the largest option (8MB) for the default TSEG size. Michael Kinney pointed out that the SMBASE relocation in PiSmmCpuDxeSmm consumes SMRAM proportionally to the number of CPUs. From the three options available, he reported that 8MB was both necessary and sufficient for the SMBASE relocation to succeed with 255 CPUs: - http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020/focus=3137 - http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020/focus=3177 Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19039 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2025-02-06 08:47:27 +0000