summaryrefslogtreecommitdiff
path: root/OvmfPkg/PlatformPei/Platform.c
AgeCommit message (Collapse)Author
2016-05-17OvmfPkg/PlatformPei: provide 10 * 4KB of PCI IO Port space on Q35Laszlo Ersek
This can accommodate 10 bridges (including root bridges, PCIe upstream and downstream ports, etc -- see <https://bugzilla.redhat.com/show_bug.cgi?id=1333238#c12> for more details). 10 is not a whole lot, but closer to the architectural limit of 15 than our current 4, so it can be considered a stop-gap solution until all guests manage to migrate to virtio-1.0, and no longer need PCI IO BARs behind PCIe downstream ports. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu>
2016-05-17OvmfPkg/PlatformPei: set PCI IO port aperture dynamicallyLaszlo Ersek
Make PcdPciIoBase and PcdPciIoSize dynamic PCDs, and set them in MemMapInitialization(), where we produce our EFI_RESOURCE_IO descriptor HOB. (The PCD is consumed by the core PciHostBridgeDxe driver, through our PciHostBridgeLib instance.) Take special care to keep the GCD IO space map unchanged on all platforms OVMF runs on. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu>
2016-05-17OvmfPkg: determine PMBA value dependent on host bridge device IDLaszlo Ersek
In this patch, the AcpiTimerLib instances, ResetSystemLib, and PlatformPei are modified together in order to keep VMs functional across a bisection: they all must agree on the PMBA value used. ResetSystemLib must not use dynamic PCDs. With SOURCE_DEBUG_ENABLE, it gets linked into the debug agent, therefore the same restrictions apply to it as to BaseRomAcpiTimerLib. Luckily, AcpiPmControl() is only used for powering off the virtual machine, thus the extra cost of a PCI config space read, compared to a PcdGet16(), should be negligible. This is the patch that moves the PMBA to IO port 0x0600 on Q35 in practice. The ResetSystemLib change is easiest to verify with the "reset -s" command in the UEFI shell (which goes through gRT->ResetSystem() and, in OVMF, PcAtChipsetPkg/KbcResetDxe). Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu>
2016-05-17OvmfPkg: add and use industry standard macro PIIX4_PMBA_MASKLaszlo Ersek
We already have the identical purpose (but different value) macro for ICH9, namely ICH9_PMBASE_MASK in "OvmfPkg/Include/IndustryStandard/Q35MchIch9.h". Also, stop bit-negating signed integer constants. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu>
2016-05-17OvmfPkg: replace PcdAcpiPmBaseAddress with PIIX4_PMBA_VALUELaszlo Ersek
In the next patches, we'll differentiate the PMBA IO port address that we program on PIIX4 vs. Q35. Normally we'd just turn PcdAcpiPmBaseAddress into a dynamic PCD. However, because we need this value in BaseRomAcpiTimerLib too (which cannot access RAM and dynamic PCDs), it must remain a build time constant. We will introduce its Q35 counterpart later. As first step, replace the PCD with a new macro in "OvmfPlatforms.h"; Jordan prefers the latter to fixed PCDs in this instance. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu>
2016-05-04OvmfPkg/PlatformPei: Add memory above 4GB as testedRuiyu Ni
Since PlatformBootManagerLib do not run memory test to convert untested memory to tested. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2016-04-07OvmfPkg: Set PcdAcpiS3Enable according to QemuFwCfgS3Enabled()Star Zeng
Also need to declare PcdAcpiS3Enable as DynamicDefault in *.dsc. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2016-03-19OvmfPkg/PlatformPei: suppress wrong VS2008 warning (use of uninited local)Laszlo Ersek
VS2008 seems to think that the "PciExBarBase" variable (introduced in commit 7b8fe63561b4) can be evaluated for the AddReservedMemoryBaseSizeHob() function call with its value being uninitialized / indeterminate. This is not the case (see "mHostBridgeDevId"); suppress the warning. Reported-by: David Woodhouse <dwmw2@infradead.org> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/8871/focus=9431 Cc: David Woodhouse <dwmw2@infradead.org> 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: David Woodhouse <David.Woodhouse@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-10OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35Laszlo Ersek
The comments in the code should speak for themselves; here we note only two facts: - The PCI config space writes (to the PCIEXBAR register) are performed using the 0xCF8 / 0xCFC IO ports, by virtue of PciLib being resolved to BasePciLibCf8. (This library resolution will permanently remain in place for the PEI phase.) - Since PCIEXBAR counts as a chipset register, it is the responsibility of the firmware to reprogram it at S3 resume. Therefore PciExBarInitialization() is called regardless of the boot path. (Marcel recently posted patches for SeaBIOS that implement this.) This patch suffices to enable PCIEXBAR (and the dependent ACPI table generation in QEMU), for the sake of "PCIeHotplug" in the Linux guest: ACPI: MCFG 0x000000007E17F000 00003C (v01 BOCHS BXPCMCFG 00000001 BXPC 00000001) PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820 acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability] In the following patches, we'll equip the core PCI host bridge / root bridge driver and the rest of DXE as well to utilize ECAM on Q35. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Michał Zegan <webczat_200@poczta.onet.pl> Ref: https://github.com/tianocore/edk2/issues/32 Ref: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/10548 Suggested-by: Marcel Apfelbaum <marcel@redhat.com> Reported-by: Michał Zegan <webczat_200@poczta.onet.pl> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Michał Zegan <webczat_200@poczta.onet.pl> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-10OvmfPkg: PlatformPei: lower the 32-bit PCI MMIO base to 2GB on Q35Laszlo Ersek
Gerd has advised us that long term support Q35 machine types have no low RAM above 2GB, hence we should utilize the [2GB, 3GB) gap -- that we currently leave unused -- for MMIO. (Plus, later in this series, for the PCIEXBAR too.) Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Michał Zegan <webczat_200@poczta.onet.pl> Ref: https://github.com/tianocore/edk2/issues/32 Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/8707/focus=8817 Suggested-by: Gerd Hoffmann <kraxel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Michał Zegan <webczat_200@poczta.onet.pl> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03OvmfPkg: factor the MMIO aperture shared by all PCI root bridges into PCDsLaszlo Ersek
Going forward, two modules will need to know about the aperture: PlatformPei (as before), and OVMF's upcoming PciHostBridgeLib instance (because the core PciHostBridgeDxe driver requires the library to state the exact apertures for all root bridges). On QEMU, all root bridges share the same MMIO aperture, hence one pair of PCDs suffices. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@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>
2016-03-03OvmfPkg: factor the IO aperture shared by all PCI root bridges into PCDsLaszlo Ersek
At the moment we don't intend to customize this aperture at runtime, but going forward, two modules will need to know about it: PlatformPei (as before), and OVMF's upcoming PciHostBridgeLib instance (because the core PciHostBridgeDxe driver requires the library to state the exact apertures for all root bridges). On QEMU, all root bridges share the same IO port aperture, hence one pair of PCDs suffices. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@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>
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-30OvmfPkg: PlatformPei: allow caching in AddReservedMemoryBaseSizeHob()Laszlo Ersek
AddReservedMemoryBaseSizeHob() should be able to set the same resource attributes for reserved memory as AddMemoryBaseSizeHob() sets for system memory. Add a new parameter called "Cacheable" to AddReservedMemoryBaseSizeHob(), and set it to FALSE in the only caller we have at the moment. 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@19038 6f19259b-4bc3-4df7-8a09-765794883524
2015-09-15OvmfPkg: PlatformPei: take no-exec DXE settings from the QEMU command lineLaszlo Ersek
Control them with: -fw_cfg name=opt/ovmf/PcdPropertiesTableEnable,file=no.txt \ -fw_cfg name=opt/ovmf/PcdSetNxForStack,file=yes.txt where the contents of the text files can be [0nN1yY](\n|\r\n)? The macro trickery is not optimal, but it is caused by PcdSetBool(), which is itself a macro, and can only take open-coded PCD names (ie. no variables, like function parameters). 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@18471 6f19259b-4bc3-4df7-8a09-765794883524
2015-09-02OvmfPkg: PlatformPei: force 32-bit MMIO aperture above 3 GB on Q35Laszlo Ersek
The logic we have in place for i440fx does not work reliably on q35. For example, if the guest has 2GB of RAM, we allow the PCI root bridge driver to allocate the legacy video RAM BAR from the [2048 MB, 2816 MB] range, which falls strictly outside of the Q35 PCI host MMIO aperture that QEMU configures, and advertizes in ACPI. In turn, PCI BARs that exist outside of the PCI host aperture that is exposed in ACPI break Windows guests. Allocating PCI MMIO resources at or above 3GB on Q35 ensures that we stay within QEMU's aperture. (See the "w32.begin" assignments in "hw/pci-host/q35.c".) Furthermore, in pc_q35_init() (file "hw/i386/pc_q35.c"), QEMU ensures that the low RAM never "leaks" above 3GB. The i440fx logic is left unchanged. The Windows guest malfunction on Q35 was reported by Jon Panozzo of Lime Technology, Inc. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jon Panozzo <jonp@lime-technology.com> Cc: "Gabriel L. Somlo" <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Jonathan Panozzo <jonp@lime-technology.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18393 6f19259b-4bc3-4df7-8a09-765794883524
2015-09-02OvmfPkg: PlatformPei: clear CMOS 0xF after setting mBootModeLaszlo Ersek
We have an old bug in BootModeInitialization(): firmware is supposed to clear the CMOS register 0xF after reading it for the last time. QEMU only sets this register to 0xFE in "hw/timer/mc146818rtc.c", function rtc_notify_suspend(), and never clears it. However, SeaBIOS does clear it in "src/post.c" and "src/resume.c", so let's follow suit. We've never noticed this until now because the register gets mysteriously cleared on non-resume reboots when OVMF runs on qemu-system-x86_64. But on qemu-system-i386, this bug breaks a (suspend, resume, reboot) triplet: after the last step OVMF thinks it's resuming because when it actually resumed (in the middle step), it failed to clear the register. BootModeInitialization() is the perfect function to clear the register, right after setting mBootMode: the function is executed on both normal boot and on S3 resume; it succeeds DebugDumpCmos() -- so the dump is not affected by this patch --; and everything that relies on S3 vs. normal boot after we clear the register uses mBootMode anyway. 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@18391 6f19259b-4bc3-4df7-8a09-765794883524
2015-08-06OvmfPkg: set SMBIOS version in DetectSmbiosVersionLib instead of PlatformPeiLaszlo Ersek
This patch de-duplicates the logic added in commit OvmfPkg: PlatformPei: set SMBIOS entry point version dynamically (git 37baf06b, SVN r17676) by hooking DetectSmbiosVersionLib into SmbiosDxe. Although said commit was supposed to work with SMBIOS 3.0 payloads from QEMU, in practice that never worked, because the size / signature checks in SmbiosVersionInitialization() would always fail, due to the SMBIOS 3.0 entry point being structurally different. Therefore this patch doesn't regress OvmfPkg. Cc: Wei Huang <wei@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gabriel L. Somlo <somlo@cmu.edu> 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@18175 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-28OvmfPkg: fix conversion specifiers in DEBUG format stringsLaszlo Ersek
Cc: Scott Duplichan <scott@notabs.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Reported-by: Scott Duplichan <scott@notabs.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18095 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-26OvmfPkg: PlatformPei: create the CPU HOB with dynamic memory space widthLaszlo Ersek
Maoming reported that guest memory sizes equal to or larger than 64GB were not correctly handled by OVMF. Enabling the DEBUG_GCD (0x00100000) bit in PcdDebugPrintErrorLevel, and starting QEMU with 64GB guest RAM size, I found the following error in the OVMF debug log: > GCD:AddMemorySpace(Base=0000000100000000,Length=0000000F40000000) > GcdMemoryType = Reserved > Capabilities = 030000000000000F > Status = Unsupported This message is emitted when the DXE core is initializing the memory space map, processing the "above 4GB" memory resource descriptor HOB that was created by OVMF's QemuInitializeRam() function (see "UpperMemorySize"). The DXE core's call chain fails in: CoreInternalAddMemorySpace() [MdeModulePkg/Core/Dxe/Gcd/Gcd.c] CoreConvertSpace() // // Search for the list of descriptors that cover the range BaseAddress // to BaseAddress+Length // CoreSearchGcdMapEntry() CoreSearchGcdMapEntry() fails because the one entry (with type "nonexistent") in the initial GCD memory space map is too small, and cannot be split to cover the memory space range being added: > GCD:Initial GCD Memory Space Map > GCDMemType Range Capabilities Attributes > ========== ================================= ================ ================ > NonExist 0000000000000000-0000000FFFFFFFFF 0000000000000000 0000000000000000 The size of this initial entry is determined from the CPU HOB (CoreInitializeGcdServices()). Set the SizeOfMemorySpace field in the CPU HOB to mPhysMemAddressWidth, which is the narrowest valid value to cover the entire guest RAM. Reported-by: Maoming <maoming.maoming@huawei.com> Cc: Maoming <maoming.maoming@huawei.com> Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com> Cc: Wei Liu <wei.liu2@citrix.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Wei Liu <wei.liu2@citrix.com> Tested-by: Maoming <maoming.maoming@huawei.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17720 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-26OvmfPkg: PlatformPei: enable larger permanent PEI RAMLaszlo Ersek
We'll soon increase the maximum guest-physical RAM size supported by OVMF. For more RAM, the DXE IPL is going to build more page tables, and for that it's going to need a bigger chunk from the permanent PEI RAM. Otherwise CreateIdentityMappingPageTables() would fail with: > DXE IPL Entry > Loading PEIM at 0x000BFF61000 EntryPoint=0x000BFF61260 DxeCore.efi > Loading DXE CORE at 0x000BFF61000 EntryPoint=0x000BFF61260 > AllocatePages failed: No 0x40201 Pages is available. > There is only left 0x3F1F pages memory resource to be allocated. > ASSERT .../MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c(123): > BigPageAddress != 0 (The above example belongs to the artificially high, maximal address width of 52, clamped by the DXE core to 48. The address width of 48 bits corresponds to 256 TB or RAM, and requires a bit more than 1GB for paging structures.) Cc: Maoming <maoming.maoming@huawei.com> Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com> Cc: Wei Liu <wei.liu2@citrix.com> Cc: Brian J. Johnson <bjohnson@sgi.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brian J. Johnson <bjohnson@sgi.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17719 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-22OvmfPkg: PlatformPei: set SMBIOS entry point version dynamicallyLaszlo Ersek
Git commit 54753b60 (SVN r16870), "MdeModulePkg: Update SMBIOS revision to 3.0." changed PcdSmbiosVersion from 0x0208 to 0x0300. This controls the version number of the SMBIOS entry point table (and other things) that "MdeModulePkg/Universal/SmbiosDxe" installs. Alas, this change breaks older Linux guests, like RHEL-6 (up to RHEL-6.7); those are limited to 2.x (both in the guest kernel firmware driver, and in the dmidecode utility). The SMBIOS 3.0 entry point has a different GUID -- defined in UEFI 2.5 -- pointing to it in the UEFI Configuration Table, and guest kernels that lack upstream kernel commit e1ccbbc9d5 don't recognize it. The v2.1.0+ machine types of QEMU generate SMBIOS payload for the firmware to install. The payload includes the entry point table ("anchor" table). OvmfPkg/SmbiosPlatformDxe cannot install the anchor table (because that is the jurisdiction of the generic "MdeModulePkg/Universal/SmbiosDxe" driver); however, we can parse the entry point version from QEMU's anchor table, and instruct "MdeModulePkg/Universal/SmbiosDxe" to adhere to that version. On machine types older than v2.1.0, the feature is not available, but then, should anything in OVMF install SMBIOS tables, version 2.8 is simply safer / more widely supported than 3.0 -- hence the default 2.8 value for the dynamic PCD. We set the PCD in PlatformPei (when not on the S3 resume path), because that's an easy and certain way to set the PCD before a DXE driver reads it. This follows the example of PcdEmuVariableNvStoreReserved (which is read by EmuVariableFvbRuntimeDxe). RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1232876 Cc: Gabriel Somlo <somlo@cmu.edu> 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> Acked-by: Gabriel Somlo <somlo@cmu.edu> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17676 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-09OvmfPkg/PlatformPei: Initialise RCBA (B0:D31:F0 0xf0) registerPaulo Alcantara
This patch initialises root complex register block BAR in order to support TCO watchdog emulation features (e.g. reboot upon NO_REBOOT bit not set) on QEMU. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paulo Alcantara <pcacjr@zytor.com> Reviewed-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@17601 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-09OvmfPkg/PlatformPei: Query Host Bridge DID only oncePaulo Alcantara
Make HostBridgeDevId global so MemMapInitialization() can also use it to conditionally add RCRB MMIO address to HOB. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paulo Alcantara <pcacjr@zytor.com> Reviewed-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@17600 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: consolidate POWER_MGMT_REGISTER_PIIX4() on "I440FxPiix4.h" macrosLaszlo Ersek
All POWER_MGMT_REGISTER_PIIX4() macro invocations in OvmfPkg should use the macros in "I440FxPiix4.h" as arguments. Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17435 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: consolidate POWER_MGMT_REGISTER_Q35() on "Q35MchIch9.h" macrosLaszlo Ersek
All POWER_MGMT_REGISTER_Q35() macro invocations in OvmfPkg should use the macros in "Q35MchIch9.h" as arguments. Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17434 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-26OvmfPkg: Q35: Use correct ACPI PM control register:bitGabriel Somlo
On PIIX4, function 3, the PMREGMISC register at offset 0x80, with default value 0x00 has its bit 0 (PMIOSE) indicate whether the PM IO space given in the PMBA register (offset 0x40) is enabled. PMBA must be configured *before* setting this bit. On Q35/ICH9+, function 0x1f, the equivalent role is fulfilled by bit 7 (ACPI_EN) in the ACPI Control Register (ACPI_CNTL) at offset 0x44, also with a default value of 0x00. Currently, OVMF hangs when Q35 reboots, because while PMBA is reset by QEMU, the register at offset 0x80 (matching PMREGMISC on PIIX4) is not reset, since it has a completely different meaning on LPC. As such, the power management initialization logic in OVMF finds the "PMIOSE" bit enabled after a reboot and decides to skip setting PMBA. This causes the ACPI timer tick routine to read a constant value from the wrong register, which in turn causes the ACPI delay loop to hang indefinitely. This patch modifies the Base[Rom]AcpiTimerLib constructors and the PlatformPei ACPI PM init routines to use ACPI_CNTL:ACPI_EN instead of PMREGMISC:PMIOSE when running on Q35. Reported-by: Reza Jelveh <reza.jelveh@tuhh.de> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17076 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: Add PCD for Host Bridge dev. ID (PcdOvmfHostBridgePciDevId)Gabriel Somlo
Set from PEI, this PCD allows subsequent stages (specifically DXE_DRIVER and DXE_RUNTIME_DRIVER) to infer the underlying platform type (e.g. PIIX4 or Q35/MCH) without the need to further query the Host Bridge for its Device ID. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16374 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: PlatformPei: Platform specific ACPI power management setupGabriel Somlo
Set up ACPI power management using registers determined based on the underlying (PIIX4 or Q35/MCH) platform type. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16373 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg/PlatformPei: Skip various items for S3 resumeJordan Justen
We will not be running DXE on S3 resume, so we don't need to do these initialization items: * Reserve EMU Variable memory range * Declare Firmware volumes * Add memory HOBs v5: * Move MiscInitialization back to running on S3 resume Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15295 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg/PlatformPei: Detect S3 support for QEMU / KVMJordan Justen
QEMU indicates whether S3 is supported or not in the fw-cfg interface. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15293 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg/PlatformPei: Add mBootMode driver variableJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15291 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: PlatformPei: detect S3 Resume in CMOS and set boot mode accordinglyLaszlo Ersek
Data is transferred between S3 Suspend and S3 Resume as follows: S3 Suspend (DXE): (1) BdsLibBootViaBootOption() EFI_ACPI_S3_SAVE_PROTOCOL [AcpiS3SaveDxe] - saves ACPI S3 Context to LockBox ---------------------+ (including FACS address -- FACS ACPI table | contains OS waking vector) | | - prepares boot script: | EFI_S3_SAVE_STATE_PROTOCOL.Write() [S3SaveStateDxe] | S3BootScriptLib [PiDxeS3BootScriptLib] | - opcodes & arguments are saved in NVS. --+ | | | - issues a notification by installing | | EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL | | | | (2) EFI_S3_SAVE_STATE_PROTOCOL [S3SaveStateDxe] | | S3BootScriptLib [PiDxeS3BootScriptLib] | | - closes script with special opcode <---------+ | - script is available in non-volatile memory | via PcdS3BootScriptTablePrivateDataPtr --+ | | | BootScriptExecutorDxe | | S3BootScriptLib [PiDxeS3BootScriptLib] | | - Knows about boot script location by <----+ | synchronizing with the other library | instance via | PcdS3BootScriptTablePrivateDataPtr. | - Copies relocated image of itself to | reserved memory. --------------------------------+ | - Saved image contains pointer to boot script. ---|--+ | | | | Runtime: | | | | | | (3) OS is booted, writes OS waking vector to FACS, | | | suspends machine | | | | | | S3 Resume (PEI): | | | | | | (4) PlatformPei sets S3 Boot Mode based on CMOS | | | | | | (5) DXE core is skipped and EFI_PEI_S3_RESUME2 is | | | called as last step of PEI | | | | | | (6) S3Resume2Pei retrieves from LockBox: | | | - ACPI S3 Context (path to FACS) <------------------|--|--+ | | | +------------------|--|--+ - Boot Script Executor Image <----------------------+ | | | | (7) BootScriptExecutorDxe | | S3BootScriptLib [PiDxeS3BootScriptLib] | | - executes boot script <-----------------------------+ | | (8) OS waking vector available from ACPI S3 Context / FACS <--+ is called Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [jordan.l.justen@intel.com: move code into BootModeInitialization] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15290 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-01OvmfPkg/PlatformPei: Add RAM for Xen in InitializeRamRegionsJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15207 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-01OvmfPkg/PlatformPei: Add InitializeRamRegions functionJordan Justen
In the next commit we will update the Xen boot path to also use this function. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15206 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-01OvmfPkg/PlatformPei: Merge Xen support into MemMapInitializationJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15205 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-01OvmfPkg/PlatformPei: Set PcdPciDisableBusEnumeration in InitializeXenJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15204 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-01OvmfPkg/PlatformPei: Add XenPublishRamRegionsJordan Justen
This will be called from a unified MemDetect function. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15203 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-01OvmfPkg/PlatformPei: Hide Xen Leaf detailsJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15202 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-01OvmfPkg/PlatformPei: Add mXen boolean to indicate Xen is runningJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15201 6f19259b-4bc3-4df7-8a09-765794883524
2014-01-29OvmfPkg/PlatformPei: Move BootMode detection before mem-initJordan Justen
This will be needed to update the boot flow for S3 resume. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15196 6f19259b-4bc3-4df7-8a09-765794883524
2014-01-29OvmfPkg/PlatformPei: Call PublishPeiMemory in one placeJordan Justen
The Xen and QEMU/KVM paths were calling this at nearly the same time in the boot flow anyhow, so just make the call in one spot. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15195 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-08OvmfPkg: enable Xen specific pathWei Liu
This patch sets PcdPciDisableBusEnumeration to true then makes use of PublishPeiMemory and XenMemMapInitialization to construct memory map for Xen guest. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14946 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-08OvmfPkg: introduce XenMemMapInitializationWei Liu
This function parses E820 map provided by Xen and arrange memory maps accordingly. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [jordan.l.justen@intel.com: XenGetE820Map: VS2010 compat; add assert] 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@14945 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-08OvmfPkg: detect Xen earlierWei Liu
This is useful for initializing memory map. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14943 6f19259b-4bc3-4df7-8a09-765794883524
2013-10-29OvmfPkg/PlatformPei: emulated NV storage must be EfiRuntimeServicesDataLaszlo Ersek
SVN r14770 ("OvmfPkg/PlatformPei: correctly align emulated NV storage") made sure the emulated NV storage was allocated with correct alignment. However, the AllocateRuntimePool() -> AllocateAlignedPages() change flipped the memory type from EfiRuntimeServicesData to EfiBootServicesData. This causes variable services to access freed storage at runtime. It crashes Windows 2008 R2 early at boot, for example. Keep the alignment, but restore the memory type to EfiRuntimeServicesData, by calling AllocateAlignedRuntimePages(). These helper functions are implemeted and documented in "MdePkg/Library/PeiMemoryAllocationLib/MemoryAllocationLib.c". 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@14806 6f19259b-4bc3-4df7-8a09-765794883524
2013-10-14OvmfPkg/PlatformPei: correctly align emulated NV storageWei Liu
Per 2c4b18e ("MdeModulePkg: Add the alignment check for FTW spare area address and length, and add the check for PcdFlashNvStorageVariableSize <= PcdFlashNvStorageFtwSpareSize."), FTWDxe refuses to initialize if spare space base address or size is not aligned to block size. Depending on configuration, memory for FTWDxe might be dynamically allocated in PlatformPei. This patch makes sure that the allocated memory region is aligned. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14770 6f19259b-4bc3-4df7-8a09-765794883524
2012-09-12OvmfPkg: key PMBA setup in Platform PEI off of PMREGMISC/PMIOSE, not Xenjljusten
This matches the logic in AcpiTimerLib. 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13723 6f19259b-4bc3-4df7-8a09-765794883524
2012-09-12OvmfPkg: enable PIIX4 IO space in the PEI phasejljusten
I. There are at least three locations in OvmfPkg that manipulate the PMBA and related PIIX4 registers. 1. MiscInitialization() [OvmfPkg/PlatformPei/Platform.c] module type: PEIM -- Pre-EFI Initialization Module (a) currently sets the PMBA only: 00.01.3 / 0x40 bits [15:6] 2. AcpiTimerLibConstructor() [OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c] module type: BASE -- probably callable anywhere after PEI (a) sets the PMBA if needed: 00.01.3 / 0x40 bits [15:6] (b) sets PCICMD/IOSE if needed: 00.01.3 / 0x04 bit 0 (c) sets PMREGMISC/PMIOSE: 00.01.3 / 0x80 bit 0 3. AcpiInitialization() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c] module type: DXE_DRIVER -- Driver eXecution Environment (a) sets SCI_EN, which depends on correct PMBA setting from earlier ( The relative order of #1 and #3 is dictated minimally by their module types. Said relative order can be verified with the boot log: 27 Loading PEIM at 0x00000822320 EntryPoint=0x00000822580 PlatformPei.efi 28 Platform PEIM Loaded 1259 PlatformBdsInit 1270 PlatformBdsPolicyBehavior Line 28 is printed by InitializePlatform() [OvmfPkg/PlatformPei/Platform.c] which is the entry point of that module. The other two lines are printed by the corresponding functions in "OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c". ) Currently #2 (AcpiTimerLibConstructor()) is called in a random spot (whenever it gets loaded from the firmware image) and masks the insufficient setup in #1. We shouldn't depend on that, PEI should finish with IO space being fully accessibe. In addition, PEI should program the same PMBA value as AcpiTimerLib. II. The PEI change notwithstanding, AcpiTimerLib should stay defensive and ensure proper PM configuration for itself (either by confirming or by doing). III. Considering a possible cleanup/unification of #2 and #3: timer functions relying on AcpiTimerLibConstructor(), - MicroSecondDelay() - NanoSecondDelay() - GetPerformanceCounter() - GetPerformanceCounterProperties() - GetTimeInNanoSecond() may be called before #3 is reached (in Boot Device Selection phase), so we should not move the initialization from #2 to #3. (Again, AcpiTimerLib should contain its own setup.) We should also not move #3 to an earlier phase -- SCI_EN is premature unless we're about to boot real soon ("enable generation of SCI upon assertion of PWRBTN_STS, LID_STS, THRM_STS, or GPI_STS bits"). 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13722 6f19259b-4bc3-4df7-8a09-765794883524
2012-09-12OvmfPkg: fix the mask for accessing the PIIX4 PMBA [15:6] bitfieldjljusten
The Index Register Base Address bitfield is selected by the binary mask 00000000 00000000 11111111 11000000, 0xFFC0; fix the typo. Reported-by: Gleb Natapov <gleb@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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13720 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2025-02-06 07:48:11 +0000