summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/OvmfPkg.dec
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: PlatformPei: determine the 64-bit PCI host aperture for X64 DXELaszlo Ersek2016-03-231-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main observation about the 64-bit PCI host aperture is that it is the highest part of the useful address space. It impacts the top of the GCD memory space map, and, consequently, our maximum address width calculation for the CPU HOB too. Thus, modify the GetFirstNonAddress() function to consider the following areas above the high RAM, while calculating the first non-address (i.e., the highest inclusive address, plus one): - the memory hotplug area (optional, the size comes from QEMU), - the 64-bit PCI host aperture (we set a default size). While computing the first non-address, capture the base and the size of the 64-bit PCI host aperture at once in PCDs, since they are natural parts of the calculation. (Similarly to how PcdPciMmio32* are not rewritten on the S3 resume path (see the InitializePlatform() -> MemMapInitialization() condition), nor are PcdPciMmio64*. Only the core PciHostBridgeDxe driver consumes them, through our PciHostBridgeLib instance.) Set 32GB as the default size for the aperture. Issue#59 mentions the NVIDIA Tesla K80 as an assignable device. According to nvidia.com, these cards may have 24GB of memory (probably 16GB + 8GB BARs). As a strictly experimental feature, the user can specify the size of the aperture (in MB) as well, with the QEMU option -fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536 The "X-" prefix follows the QEMU tradition (spelled "x-" there), meaning that the property is experimental, unstable, and might go away any time. Gerd has proposed heuristics for sizing the aperture automatically (based on 1GB page support and PCPU address width), but such should be delayed to a later patch (which may very well back out "X-PciMmio64Mb" then). For "everyday" guests, the 32GB default for the aperture size shouldn't impact the PEI memory demand (the size of the page tables that the DXE IPL PEIM builds). Namely, we've never reported narrower than 36-bit addresses; the DXE IPL PEIM has always built page tables for 64GB at least. For the aperture to bump the address width above 36 bits, either the guest must have quite a bit of memory itself (in which case the additional PEI memory demand shouldn't matter), or the user must specify a large aperture manually with "X-PciMmio64Mb" (and then he or she is also responsible for giving enough RAM to the VM, to satisfy the PEI memory demand). Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Thomas Lamprecht <t.lamprecht@proxmox.com> Ref: https://github.com/tianocore/edk2/issues/59 Ref: http://www.nvidia.com/object/tesla-servers.html Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: introduce gRootBridgesConnectedEventGroupGuidLaszlo Ersek2016-03-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QEMU's ACPI table generator can only create meaningful _CRS objects -- apertures -- for the root buses if all of the PCI devices behind those buses are actively decoding their IO and MMIO resources, at the time of the firmware fetching the "etc/table-loader" fw_cfg file. This is not a QEMU error; QEMU follows the definition of BARs (which are meaningless when decoding is disabled). Currently we hook up AcpiPlatformDxe to the PCI Bus driver's gEfiPciEnumerationCompleteProtocolGuid cue. Unfortunately, when the PCI Bus driver installs this protocol, it's *still* not the right time for fetching "etc/table-loader": although resources have been allocated and BARs have been programmed with them, the PCI Bus driver has also cleared IO and MMIO decoding in the command registers of the devices. Furthermore, we couldn't reenable IO and MMIO decoding temporarily in our gEfiPciEnumerationCompleteProtocolGuid callback even if we wanted to, because at that time the PCI Bus driver has not produced PciIo instances yet. Our Platform BDSes are responsible for connecting the root bridges, hence they know exactly when the PciIo instances become available -- not when PCI enumeration completes (signaled by the above protocol), but when the ConnectController() calls return. This is when our Platform BDSes should explicitly cue in AcpiPlatformDxe. Then AcpiPlatformDxe can temporarily enable IO and MMIO decoding for all devices, while it contacts QEMU for the ACPI payload. This patch introduces the event group GUID that we'll use for unleashing AcpiPlatformDxe from our Platform BDSes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.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: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: OvmfPkg.dec: add horizontal whitespace under Guids and ProtocolsLaszlo Ersek2016-03-231-9/+9
| | | | | | | | | We'll need more room in the next patch. No functional changes. 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>
* OvmfPkg: factor the MMIO aperture shared by all PCI root bridges into PCDsLaszlo Ersek2016-03-031-0/+5
| | | | | | | | | | | | | | | | | 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>
* OvmfPkg: factor the IO aperture shared by all PCI root bridges into PCDsLaszlo Ersek2016-03-031-0/+5
| | | | | | | | | | | | | | | | | | 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>
* OvmfPkg: remove superfluous [PcdsFixedAtBuild] section headerLaszlo Ersek2016-03-031-1/+0
| | | | | | | | | | | | | At the location of this header an earlier [PcdsFixedAtBuild] section is in effect already. 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: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire setLaszlo Ersek2015-11-301-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* OvmfPkg: Sec: assert the build-time calculated end of the scratch bufferLaszlo Ersek2015-11-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more memory, temporarily, than what PEIFV and DXEFV will ultimately need. First, it uses an output buffer for decompression, second, the decompression itself needs a scratch buffer (and this scratch buffer is the highest area that SEC uses). DecompressMemFvs() used to be called on normal boots only (ie. not on S3 resume), which is why the decompression output buffer and the scratch buffer were allowed to scribble over RAM. However, we'll soon start to worry during S3 resume that the runtime OS might tamper with the pre-decompressed PEIFV, and we'll decompress the firmware volumes on S3 resume too, from pristine flash. For this we'll need to know the end of the scratch buffer in advance, so we can prepare a non-malicious OS for it. Calculate the end of the scratch buffer statically in the FDF files, and assert in DecompressMemFvs() that the runtime decompression will match it. 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@19036 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: introduce -D SMM_REQUIRE and PcdSmmSmramRequireLaszlo Ersek2015-11-301-0/+10
| | | | | | | | | | | This build time flag and corresponding Feature PCD will control whether OVMF supports (and, equivalently, requires) SMM/SMRAM support from QEMU. 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@19034 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: introduce PcdQemuSmbiosValidatedLaszlo Ersek2015-08-061-0/+1
| | | | | | | | | | | | | | | | | | | This dynamic PCD will enable a small code de-duplication between OvmfPkg/SmbiosPlatformDxe and OvmfPkg/Library/SmbiosVersionLib. Since both of those are also used in ArmVirtQemu.dsc, and we should avoid cross-package commits when possible, this patch declares PcdQemuSmbiosValidated first, and sets defaults for it in the OvmfPkg DSC files. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Wei Huang <wei@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.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> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18178 6f19259b-4bc3-4df7-8a09-765794883524
* ArmVirtualizationPkg: add XenIoMmioLibArd Biesheuvel2015-02-281-0/+4
| | | | | | | | | | | | | This adds a XenIoMmioLib declaration and implementation that can be invoked to install the XENIO_PROTOCOL and a corresponding grant table address on a EFI handle. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16979 6f19259b-4bc3-4df7-8a09-765794883524
* Ovfm/Xen: add a Vendor Hardware device path GUID for the XenBus rootArd Biesheuvel2015-02-281-0/+1
| | | | | | | | | | | | | On non-PCI Xen guests (such as ARM), the XenBus root is not a PCI device but an abstract 'platform' device. Add a dedicated Vendor Hardware device path GUID to identify this node. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16978 6f19259b-4bc3-4df7-8a09-765794883524
* Ovmf/Xen: introduce XENIO_PROTOCOLArd Biesheuvel2015-02-281-0/+1
| | | | | | | | | | | | | | | | This introduces the abstract XENIO_PROTOCOL that will be used to communicate the Xen grant table address to drivers supporting this protocol. Primary purpose is allowing us to change the XenBusDxe implementation so that it can support non-PCI Xen implementations such as Xen on ARM. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16971 6f19259b-4bc3-4df7-8a09-765794883524
* Ovmf/Xen: move XenBusDxe hypercall code to separate libraryArd Biesheuvel2015-02-281-0/+4
| | | | | | | | | | | | | | | This moves all of the Xen hypercall code that was private to XenBusDxe to a new library class XenHypercallLib. This will allow us to reimplement it for ARM, and to export the Xen hypercall functionality to other parts of the code, such as a Xen console SerialPortLib driver. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16970 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuBootOrderLib: OFW-to-UEFI translation for virtio-mmioLaszlo Ersek2015-01-021-0/+1
| | | | | | | | | | | | | | | | | | | | The TranslateMmioOfwNodes() function recognizes the following OpenFirmware device paths: virtio-blk: /virtio-mmio@000000000a003c00/disk@0,0 virtio-scsi disk: /virtio-mmio@000000000a003a00/channel@0/disk@2,3 virtio-net NIC: /virtio-mmio@000000000a003e00/ethernet-phy@0 The new translation can be enabled with the "PcdQemuBootOrderMmioTranslation" Feature PCD. This PCD also controls if the "survival policy" covers unselected boot options that start with the virtio-mmio VenHw() node. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16575 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: introduce VIRTIO_MMIO_TRANSPORT_GUIDLaszlo Ersek2015-01-021-0/+1
| | | | | | | | | | | | | | | | Soon there will be more than one modules (in separate packages) that need to have an understanding about the GUID used in the VenHw() device path nodes that describe virtio-mmio transports. Define such a GUID explicitly. Preserve the current value (which happens to be the FILE_GUID of ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf) for compatibility with external users. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16572 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuBootOrderLib: featurize PCI-like device path translationLaszlo Ersek2015-01-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for adding OpenFirmware-to-UEFI translation for "MMIO-like" OFW device path fragments, let's turn the currently exclusive "PCI-like" translation into "just one" of the possible translations. - Rename TranslateOfwNodes() to TranslatePciOfwNodes(), because it is tightly coupled to "PCI-like" translations. - Rename REQUIRED_OFW_NODES to REQUIRED_PCI_OFW_NODES, because this macro is specific to TranslatePciOfwNodes(). - Introduce a new wrapper function under the original TranslateOfwNodes() name. This function is supposed to try translations in some order until a specific translation returns a status different from RETURN_UNSUPPORTED. - Introduce a new Feature PCD that controls whether PCI translation is attempted at all. - The boot option "survival policy" in BootOrderComplete() must take into account if the user was able to select PCI-like boot options. If the user had no such possibility (because the Feature PCD was off for PCI-like translation), then we ought to keep any such unselected boot options. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16571 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: extract QemuBootOrderLibLaszlo Ersek2015-01-021-0/+5
| | | | | | | | | | and rebase OvmfPkg's PlatformBdsLib on the standalone library. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16570 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add PCD for Host Bridge dev. ID (PcdOvmfHostBridgePciDevId)Gabriel Somlo2014-11-141-0/+1
| | | | | | | | | | | | | | | | 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
* OvmfPkg: Introduce XenBus Protocol.Anthony PERARD2014-10-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | This protocol will be used for communication between a PV driver (like a PV block driver) and the XenBus/XenStore. Change in V5: - Replace the license by the commonly used file header text. Change in V3: - Add disclaimer about the volatile nature of the protocol. - Add a description on the two introduced members to the protocol. Change in V2: - Comment, file header - Protocol License - Declare xen interface version earlier - Rename protocol from Xenbus to XenBus Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16262 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: PlatformPei: protect SEC's GUIDed section handler table thru S3Laszlo Ersek2014-04-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OVMF's SecMain is unique in the sense that it links against the following two libraries *in combination*: - IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/ LzmaCustomDecompressLib.inf - MdePkg/Library/BaseExtractGuidedSectionLib/ BaseExtractGuidedSectionLib.inf The ExtractGuidedSectionLib library class allows decompressor modules to register themselves (keyed by GUID) with it, and it allows clients to decompress file sections with a registered decompressor module that matches the section's GUID. BaseExtractGuidedSectionLib is a library instance (of type BASE) for this library class. It has no constructor function. LzmaCustomDecompressLib is a compatible decompressor module (of type BASE). Its section type GUID is gLzmaCustomDecompressGuid == EE4E5898-3914-4259-9D6E-DC7BD79403CF When OVMF's SecMain module starts, the LzmaCustomDecompressLib constructor function is executed, which registers its LZMA decompressor with the above GUID, by calling into BaseExtractGuidedSectionLib: LzmaDecompressLibConstructor() [GuidedSectionExtraction.c] ExtractGuidedSectionRegisterHandlers() [BaseExtractGuidedSectionLib.c] GetExtractGuidedSectionHandlerInfo() PcdGet64 (PcdGuidedExtractHandlerTableAddress) -- NOTE THIS Later, during a normal (non-S3) boot, SecMain utilizes this decompressor to get information about, and to decompress, sections of the OVMF firmware image: SecCoreStartupWithStack() [OvmfPkg/Sec/SecMain.c] SecStartupPhase2() FindAndReportEntryPoints() FindPeiCoreImageBase() DecompressMemFvs() ExtractGuidedSectionGetInfo() [BaseExtractGuidedSectionLib.c] ExtractGuidedSectionDecode() [BaseExtractGuidedSectionLib.c] Notably, only the extraction depends on full-config-boot; the registration of LzmaCustomDecompressLib occurs unconditionally in the SecMain EFI binary, triggered by the library constructor function. This is where the bug happens. BaseExtractGuidedSectionLib maintains the table of GUIDed decompressors (section handlers) at a fixed memory location; selected by PcdGuidedExtractHandlerTableAddress (declared in MdePkg.dec). The default value of this PCD is 0x1000000 (16 MB). This causes SecMain to corrupt guest OS memory during S3, leading to random crashes. Compare the following two memory dumps, the first taken right before suspending, the second taken right after resuming a RHEL-7 guest: crash> rd -8 -p 1000000 0x50 1000000: c0 00 08 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 1000010: d0 33 0c 00 00 c9 ff ff c0 10 00 01 00 88 ff ff .3.............. 1000020: 0a 6d 57 32 0f 00 00 00 38 00 00 01 00 88 ff ff .mW2....8....... 1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo 1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so......... vs. crash> rd -8 -p 1000000 0x50 1000000: 45 47 53 49 01 00 00 00 20 00 00 01 00 00 00 00 EGSI.... ....... 1000010: 20 01 00 01 00 00 00 00 a0 01 00 01 00 00 00 00 ............... 1000020: 98 58 4e ee 14 39 59 42 9d 6e dc 7b d7 94 03 cf .XN..9YB.n.{.... 1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo 1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so......... The "EGSI" signature corresponds to EXTRACT_HANDLER_INFO_SIGNATURE declared in MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.c. Additionally, the gLzmaCustomDecompressGuid (quoted above) is visible at guest-phys offset 0x1000020. Fix the problem as follows: - Carve out 4KB from the 36KB gap that we currently have between PcdOvmfLockBoxStorageBase + PcdOvmfLockBoxStorageSize == 8220 KB and PcdOvmfSecPeiTempRamBase == 8256 KB. - Point PcdGuidedExtractHandlerTableAddress to 8220 KB (0x00807000). - Cover the area with an EfiACPIMemoryNVS type memalloc HOB, if S3 is supported and we're not currently resuming. The 4KB size that we pick is an upper estimate for BaseExtractGuidedSectionLib's internal storage size. The latter is calculated as follows (see GetExtractGuidedSectionHandlerInfo()): sizeof(EXTRACT_GUIDED_SECTION_HANDLER_INFO) + // 32 PcdMaximumGuidedExtractHandler * ( sizeof(GUID) + // 16 sizeof(EXTRACT_GUIDED_SECTION_DECODE_HANDLER) + // 8 sizeof(EXTRACT_GUIDED_SECTION_GET_INFO_HANDLER) // 8 ) OVMF sets PcdMaximumGuidedExtractHandler to 16 decimal (which is the MdePkg default too), yielding 32 + 16 * (16 + 8 + 8) == 544 bytes. Regarding the lifecycle of the new area: (a) when and how it is initialized after first boot of the VM The library linked into SecMain finds that the area lacks the signature. It initializes the signature, plus the rest of the structure. This is independent of S3 support. Consumption of the area is also limited to SEC (but consumption does depend on full-config-boot). (b) how it is protected from memory allocations during DXE It is not, in the general case; and we don't need to. Nothing else links against BaseExtractGuidedSectionLib; it's OK if DXE overwrites the area. (c) how it is protected from the OS When S3 is enabled, we cover it with AcpiNVS in InitializeRamRegions(). When S3 is not supported, the range is not protected. (d) how it is accessed on the S3 resume path Examined by the library linked into SecMain. Registrations update the table in-place (based on GUID matches). (e) how it is accessed on the warm reset path If S3 is enabled, then the OS won't damage the table (due to (c)), hence see (d). If S3 is unsupported, then the OS may or may not overwrite the signature. (It likely will.) This is identical to the pre-patch status. 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@15433 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: introduce gOvmfPlatformConfigGuidLaszlo Ersek2014-03-221-0/+1
| | | | | | | | | | | | | This GUID should become a new "namespace" for UEFI variables that are specific to OVMF configuration (as opposed to standard UEFI global variables). We'll also use it as the GUID of the related HII form-set (ie. the interactive user interface). 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@15363 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: implement LockBoxLibLaszlo Ersek2014-03-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | The S3 suspend/resume infrastructure depends on the LockBox library class. The edk2 tree currently contains Null and SMM instances. The Null instance is useless, and the SMM instance would require SMM emulation by including the SMM core and adding several new drivers, which is deemed too complex. Hence add a simple LockBoxLib instance for OVMF. jordan.l.justen@intel.com: * use PCDs instead of EmuNvramLib - clear memory in PlatformPei on non S3 boots * allocate NVS memory and store a pointer to that memory - reduces memory use at fixed locations Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> 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@15301 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add section of memory to use for PEI on S3 resumeJordan Justen2014-03-041-0/+1
| | | | | | | | | | | | | | | | | This 32k section of RAM will be declared to the PEI Core on S3 resume to allow memory allocations during S3 resume PEI. If the boot mode is BOOT_ON_S3_RESUME, then we publish the pre-reserved PcdS3AcpiReservedMemory range to PEI. If the boot mode is not BOOT_ON_S3_RESUME, then we reserve this range as ACPI NVS so the OS will not use it. 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@15294 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Split MAINFV into a separate PEI and DXE FVsJordan Justen2014-01-211-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By splitting the PEI and DXE phases into separate FVs, we can only reserve the PEI FV for ACPI S3 support. This should save about 7MB. Unfortunately, this all has to happen in a single commit. DEC: * Remove PcdOvmfMemFv(Base|Size) * Add PcdOvmfPeiMemFv(Base|Size) * Add PcdOvmfDxeMemFv(Base|Size) FDF: * Add new PEIFV. Move PEI modules here. * Remove MAINFV * Add PEIFV and DXEFV into FVMAIN_COMPACT - They are added as 2 sections of a file, and compressed together so they should retain good compression * PcdOvmf(Pei|Dxe)MemFv(Base|Size) are set SEC: * Find both the PEI and DXE FVs after decompression. - Copy them separately to their memory locations. Platform PEI driver: * Fv.c: Publish both FVs as appropriate * MemDetect.c: PcdOvmfMemFv(Base|Size) => PcdOvmfDxeMemFv(Base|Size) OVMF.fd before: Non-volatile data storage FVMAIN_COMPACT uncompressed FV FFS file LZMA compressed MAINFV uncompressed individual PEI modules uncompressed FV FFS file compressed with PI_NONE DXEFV uncompressed individual DXE modules uncompressed SECFV uncompressed OVMF.fd after: Non-volatile data storage FVMAIN_COMPACT uncompressed FV FFS file LZMA compressed PEIFV uncompressed individual PEI modules uncompressed DXEFV uncompressed individual DXE modules uncompressed SECFV uncompressed 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@15151 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Move SEC/PEI Temporary RAM from 0x70000 to 0x810000Jordan Justen2014-01-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Note: The Temporary RAM memory size is being reduced from 64KB to 32KB. This still appears to be more than adequate for OVMF's early PEI phase. We will be adding another 32KB range of RAM just above this range for use on S3 resume. The range is declared as part of MEMFD, so it is easier to identify the memory range. We also now assign PCDs to the memory range. The PCDs are used to set the initial SEC/PEI stack in SEC's assembly code. The PCDs are also used in the SEC C code to setup the Temporary RAM PPI. 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@15147 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg X64 ResetVector: Move page tables from 512KB to 8MBJordan Justen2014-01-211-0/+2
| | | | | | | | | | | | | | | | | | To help consolidate OVMF fixed memory uses, we declare this range in MEMFD and thereby move it to 8MB. We also now declare the table range in the FDF to set PCDs. This allows us to ASSERT that CR3 is set as expected in OVMF SEC. OvmfPkgIa32.fdf and OvmfPkgIa32X64.fdf are updated simply for consistency. 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@15146 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/VirtioDevice.h: Introduced VIRTIO_DEVICE_PROTOCOL protocolOlivier Martin2013-12-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | This protocol introduces an abstraction to access the VirtIo Configuration and Device spaces. The registers in these spaces are located at a different offset and have a different width whether the transport layer is either PCI or MMIO. This protocol would also allow to support VirtIo PCI devices with MSI-X capability in a transparent way (Device space is at a different offset when a PCIe device has MSI-X capability). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> v5: - add disclaimer (two instances) about the protocol being work in progress 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@14963 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: indicate enablement of flash variables with a dedicated PCDLaszlo Ersek2013-11-121-0/+1
| | | | | | | | | | | | | | | PcdFlashNvStorageVariableBase64 is used to arbitrate between QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, but even the latter driver sets it if we fall back to it. Allow code running later than the startup of these drivers to know about the availability of flash variables, through a dedicated PCD. 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@14843 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add flash PCD itemsJordan Justen2013-11-121-1/+11
| | | | | | | | 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@14834 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add LoadLinuxLib library interfacejljusten2012-11-021-0/+4
| | | | | | | | 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13921 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: introduce virtio-scsi driverjljusten2012-10-181-0/+11
| | | | | | | | | | | 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: fix build for VS2012] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13867 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: extract the PBMA used in AcpiTimerLib into a PCDjljusten2012-09-121-0/+4
| | | | | | | | 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@13719 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: assorted whitespace removaljljusten2012-09-121-2/+1
| | | | | | | | 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@13718 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: add support for debug console on port 0x402jljusten2012-07-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | This patch adds support for a debug console on the same port that is used by SeaBIOS. This makes it easier to debug OVMF, because it does not mix debug and serial output on the same device. It also makes it easier to leave some of the debug messages on even in release builds. To enable it, pass "-debugcon stdio -global isa-debugcon.iobase=0x402" to QEMU. The new mechanism is enabled by default, but a regular serial console can be chosen by adding -D DEBUG_ON_SERIAL_PORT to the build options. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [jordan.l.justen@intel.com: MAX_DEBUG_MESSAGE_LENGTH=>0x100, p=>Ptr] Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13562 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add QemuFwCfgLib library class and implementationjljusten2012-05-301-1/+5
| | | | | | | | | | | QEMU's Firmware Configuration interface gives the firmware access to various types of information. 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13383 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add PcdSecureBootEnablejljusten2012-03-091-0/+3
| | | | | | | | Signed-off-by: lgrosenb Reviewed-by: jljusten Reviewed-by: mdkinney git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13091 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/Include/Guid: Add XenInfo GUIDjljusten2011-07-291-0/+1
| | | | | | | | | | XenInfo HOB is used to pass XenInfo from PEI to DXE. Signed-off-by: Andrei Warkentin <andreiw@motorola.com> Reviewed-by: gavinguan Reviewed-by: jljusten git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12059 6f19259b-4bc3-4df7-8a09-765794883524
* Clean up invalid keywords and missing keywords in [Define] section of ↵lzeng142011-06-281-1/+1
| | | | | | | | | | INF/DEC files. Signed-off-by: lzeng14 Reviewed-by: lhauch Reviewed-by: jljusten git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11906 6f19259b-4bc3-4df7-8a09-765794883524
* Clean up DEC files:mdkinney2011-05-091-9/+9
| | | | | | | | | | | | 1) Remove section header comment blocks that do not provide any information 2) Combine PCDs listed in multiple sections into a single section that supports multiple PCD types to reduce maintenance overhead 3) Remove ModuleTypeList comments from [Includes], [Protocols], [Ppis], and [Guids] sections that do not properly describe the module type restrictions. 4) Clean up formatting of GUID structure declarations 5) Remove ".common" from section names if they are not required. 6) Order sections consistently as [Defines], [Includes], [LibraryClasses], [Guid], [Ppis], [Protocols], [PcdsFeatureFlag], [PcdsFixedAtBuild], [PcdsPatchableInModule], [PcdsDynamic], and [PcdsDynamicEx] git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11633 6f19259b-4bc3-4df7-8a09-765794883524
* Fix DEC files so any PCD declared as Dynamic is also declared as DynamicExmdkinney2011-05-051-1/+1
| | | | git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11625 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add SerializeVariablesLib library classjljusten2011-01-301-1/+5
| | | | | | | | This library provides an interface for converting the system variables into a binary and also restoring the system variables from that binary. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11284 6f19259b-4bc3-4df7-8a09-765794883524
* Fix PCD token value conflict issue.gikidy2010-11-021-2/+2
| | | | git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10996 6f19259b-4bc3-4df7-8a09-765794883524
* Update the copyright notice formathhtian2010-04-281-2/+2
| | | | git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10439 6f19259b-4bc3-4df7-8a09-765794883524
* OVMF: Add Block MMIO protocol definitionjljusten2010-03-211-0/+3
| | | | | | | | | | | | This protocol is similar to the standard UEFI BlockIo protocol, except it has no function calls and simply defines a base address in memory where reads & writes for the block device should occur. One planned usage is to fill a memory region with a small disk image, and allow it to be used as a normal disk by the standard drivers. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10295 6f19259b-4bc3-4df7-8a09-765794883524
* 1. Correct File header to ## @filelgao42010-02-231-4/+4
| | | | | | 2. Remove unnecessary .common] postfix on section. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10051 6f19259b-4bc3-4df7-8a09-765794883524
* OVMF: Update OVMF FD/FV build to minimize ROM sizejljusten2010-01-041-7/+2
| | | | | | | | | * Only SEC is uncompressed now * The MAIN FV with PEI & DXE can easily shrink and grow as needed * The final output will now be OVMF.Fv rather than OVMF.fd * The final output size will be a multiple of 64kb git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9672 6f19259b-4bc3-4df7-8a09-765794883524
* OVMF: Add library to customize the EMU Variable FVB driver.jljusten2009-09-261-8/+11
| | | | git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9316 6f19259b-4bc3-4df7-8a09-765794883524
* Implement NvVarsFileLib to save and restore non-volatile variables using a file.jljusten2009-09-161-0/+7
| | | | | | | | | | This library provides an interface where variables can be saved and restored using a file in a file system accessible to the firmware. It is expected that a platform BDS library will use this library. The platform BDS implementation can decide which devices to connect and then to attempt to use for saving and restoring NV variables. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9272 6f19259b-4bc3-4df7-8a09-765794883524
* Add initial version of Open Virtual Machine Firmware (OVMF) platform.jljusten2009-05-271-0/+34
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@8398 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-26 22:26:01 +0000