summaryrefslogtreecommitdiff
path: root/OvmfPkg/OvmfPkg.dec
AgeCommit message (Collapse)AuthorFilesLines
2018-05-24OvmfPkg: introduce PciCapPciIoLibLaszlo Ersek1-0/+5
Add a library class, and a UEFI_DRIVER lib instance, that are layered on top of PciCapLib, and allow clients to plug an EFI_PCI_IO_PROTOCOL backend into PciCapLib, for config space access. (Side note: Although the UEFI spec says that EFI_PCI_IO_PROTOCOL_CONFIG() returns EFI_UNSUPPORTED if "[t]he address range specified by Offset, Width, and Count is not valid for the PCI configuration header of the PCI controller", this patch doesn't directly document the EFI_UNSUPPORTED error code, for ProtoDevTransferConfig() and its callers ProtoDevReadConfig() and ProtoDevWriteConfig(). Instead, the patch refers to "unspecified error codes". The reason is that in edk2, the PciIoConfigRead() and PciIoConfigWrite() functions [1] can also return EFI_INVALID_PARAMETER for the above situation. Namely, PciIoConfigRead() and PciIoConfigWrite() first call PciIoVerifyConfigAccess(), which indeed produces the standard EFI_UNSUPPORTED error code, if the device's config space is exceeded. However, if PciIoVerifyConfigAccess() passes, and we reach RootBridgeIoPciRead() and RootBridgeIoPciWrite() [2], then RootBridgeIoCheckParameter() can still fail, e.g. if the root bridge doesn't support extended config space (see commit 014b472053ae3). For all kinds of Limit violations in IO, MMIO, and config space, RootBridgeIoCheckParameter() returns EFI_INVALID_PARAMETER, not EFI_UNSUPPORTED. That error code is then propagated up to, and out of, PciIoConfigRead() and PciIoConfigWrite(). [1] MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c [2] MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c ) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-05-24OvmfPkg: introduce PciCapPciSegmentLibLaszlo Ersek1-0/+5
Add a library class, and a BASE lib instance, that are layered on top of PciCapLib, and allow clients to plug a PciSegmentLib backend into PciCapLib, for config space access. (Side note: The "MaxDomain" parameter is provided because, in practice, platforms exist where a PCI Express device may show up on a root bridge such that the root bridge doesn't support access to extended config space. Earlier the same issue was handled for MdeModulePkg/PciHostBridgeDxe in commit 014b472053ae3. However, that solution does not apply to the PciSegmentLib class, because: (1) The config space accessor functions of the PciSegmentLib class, such as PciSegmentReadBuffer(), have no way of informing the caller whether access to extended config space actually succeeds. (For example, in the UefiPciSegmentLibPciRootBridgeIo instace, which could in theory benefit from commit 014b472053ae3, the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() status code is explicitly ignored, because there's no way for the lib instance to propagate it to the PciSegmentLib caller. If the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() call fails, then DxePciSegmentLibPciRootBridgeIoReadWorker() returns Data with indeterminate value.) (2) There is no *general* way for any firmware platform to provide, or use, a PciSegmentLib instance in which access to extended config space always succeeds. In brief, on a platform where config space may be limited to 256 bytes, access to extended config space through PciSegmentLib may invoke undefined behavior; therefore PciCapPciSegmentLib must give platforms a way to prevent such access.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-05-24OvmfPkg: introduce PciCapLibLaszlo Ersek1-0/+4
Add a library class, and a BASE lib instance, to work more easily with PCI capabilities in PCI config space. Functions are provided to parse capabilities lists, and to locate, describe, read and write capabilities. PCI config space access is abstracted away. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-04-10OvmfPkg: remove BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxeLaszlo Ersek1-1/+0
BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxe were introduced to OvmfPkg in March 2010, in adjacent commits b0f5144676fa and efd82c5794ec. In the past eight years, no driver or application seems to have materialized that produced BLOCK_MMIO_PROTOCOL instances. Meanwhile the UEFI spec has developed the EFI_RAM_DISK_PROTOCOL, which edk2 implements (and OVMF includes) as RamDiskDxe. Rather than fixing issues in the unused BlockMmioToBlockIoDxe driver, remove the driver, together with the BLOCK_MMIO_PROTOCOL definition that now becomes unused too. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Steven Shi <steven.shi@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=926 Reported-by: Steven Shi <steven.shi@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-10OvmfPkg: Introduce IoMmuAbsent Protocol GUIDBrijesh Singh1-0/+1
Platforms that optionally provide an IOMMU protocol should do so by including a DXE driver (usually called IoMmuDxe) that produces either the IOMMU protocol -- if the underlying capabilities are available --, or gIoMmuAbsentProtocolGuid, to signal that the IOMMU capability detection completed with negative result (i.e., no IOMMU will be available in the system). In turn, DXE drivers (and library instances) that are supposed to use the IOMMU protocol if it is available should add the following to their DEPEX: gEdkiiIoMmuProtocolGuid OR gIoMmuAbsentProtocolGuid This ensures these client modules will only be dispatched after IOMMU detection completes (with positive or negative result). Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-05OvmfPkg: mention the extended TSEG near the PcdQ35TsegMbytes declarationLaszlo Ersek1-3/+4
PlatformPei can now overwrite PcdQ35TsegMbytes; document this in "OvmfPkg/OvmfPkg.dec". 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>
2017-07-05OvmfPkg: make PcdQ35TsegMbytes dynamicLaszlo Ersek1-7/+7
We can now make PcdQ35TsegMbytes dynamic, in preparation for the extended TSEG size feature. At the moment we only move the declaration in OvmfPkg.dec from [PcdsFixedAtBuild] to [PcdsDynamic, PcdsDynamicEx], and provide the dynamic defaults (with the same value, 8) in the DSC files if SMM_REQUIRE is TRUE. 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>
2017-07-05OvmfPkg: widen PcdQ35TsegMbytes to UINT16Laszlo Ersek1-1/+1
Widen PcdQ35TsegMbytes to UINT16, in preparation for setting it dynamically to the QEMU-advertized extended TSEG size (which is 16-bits wide). 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>
2017-05-18OvmfPkg: remove gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnableLaszlo Ersek1-1/+0
This PCD is no longer used. 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>
2017-03-14OvmfPkg: introduce QemuFwCfgS3Lib classLaszlo Ersek1-0/+4
This library class will enable driver modules (a) to query whether S3 support was enabled on the QEMU command line, (b) to produce fw_cfg DMA operations that are to be replayed at S3 resume time. Declare the library class in OvmfPkg/OvmfPkg.dec, and add the library class header under OvmfPkg/Include/Library/. At the moment, the only API we expose is QemuFwCfgS3Enabled(), which we'll first migrate from QemuFwCfgLib. Further interfaces will be added in later patches. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 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>
2016-07-15OvmfPkg: remove PcdS3AcpiReservedMemoryBase, PcdS3AcpiReservedMemorySizeLaszlo Ersek1-1/+0
No module in OvmfPkg uses these PCDs any longer. The first PCD mentioned is declared by OvmfPkg, so we can remove even the declaration. The second PCD comes from IntelFrameworkModulePkg. The module that consumes PcdS3AcpiReservedMemorySize is called "IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe", and it is built into OVMF. However, AcpiS3SaveDxe consumes the PCD only conditionally: it depends on the feature PCD called PcdFrameworkCompatibilitySupport, which we never enable in OVMF. The 32KB gap that used to be the S3 permanent PEI memory is left unused in MEMFD for now; it never hurts to have a few KB available there, for future features. Cc: Jeff Fan <jeff.fan@intel.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: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-05-17OvmfPkg/PlatformPei: set PCI IO port aperture dynamicallyLaszlo Ersek1-5/+5
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: replace PcdAcpiPmBaseAddress with PIIX4_PMBA_VALUELaszlo Ersek1-4/+0
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-03-23OvmfPkg: PlatformPei: determine the 64-bit PCI host aperture for X64 DXELaszlo Ersek1-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>
2016-03-23OvmfPkg: introduce gRootBridgesConnectedEventGroupGuidLaszlo Ersek1-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>
2016-03-23OvmfPkg: OvmfPkg.dec: add horizontal whitespace under Guids and ProtocolsLaszlo Ersek1-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>
2016-03-03OvmfPkg: factor the MMIO aperture shared by all PCI root bridges into PCDsLaszlo Ersek1-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>
2016-03-03OvmfPkg: factor the IO aperture shared by all PCI root bridges into PCDsLaszlo Ersek1-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>
2016-03-03OvmfPkg: remove superfluous [PcdsFixedAtBuild] section headerLaszlo Ersek1-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>
2015-11-30OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire setLaszlo Ersek1-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
2015-11-30OvmfPkg: Sec: assert the build-time calculated end of the scratch bufferLaszlo Ersek1-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
2015-11-30OvmfPkg: introduce -D SMM_REQUIRE and PcdSmmSmramRequireLaszlo Ersek1-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
2015-08-06OvmfPkg: introduce PcdQemuSmbiosValidatedLaszlo Ersek1-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
2015-02-28ArmVirtualizationPkg: add XenIoMmioLibArd Biesheuvel1-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
2015-02-28Ovfm/Xen: add a Vendor Hardware device path GUID for the XenBus rootArd Biesheuvel1-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
2015-02-28Ovmf/Xen: introduce XENIO_PROTOCOLArd Biesheuvel1-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
2015-02-28Ovmf/Xen: move XenBusDxe hypercall code to separate libraryArd Biesheuvel1-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
2015-01-02OvmfPkg: QemuBootOrderLib: OFW-to-UEFI translation for virtio-mmioLaszlo Ersek1-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
2015-01-02OvmfPkg: introduce VIRTIO_MMIO_TRANSPORT_GUIDLaszlo Ersek1-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
2015-01-02OvmfPkg: QemuBootOrderLib: featurize PCI-like device path translationLaszlo Ersek1-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
2015-01-02OvmfPkg: extract QemuBootOrderLibLaszlo Ersek1-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
2014-11-14OvmfPkg: Add PCD for Host Bridge dev. ID (PcdOvmfHostBridgePciDevId)Gabriel Somlo1-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
2014-10-29OvmfPkg: Introduce XenBus Protocol.Anthony PERARD1-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
2014-04-05OvmfPkg: PlatformPei: protect SEC's GUIDed section handler table thru S3Laszlo Ersek1-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
2014-03-22OvmfPkg: introduce gOvmfPlatformConfigGuidLaszlo Ersek1-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
2014-03-04OvmfPkg: implement LockBoxLibLaszlo Ersek1-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
2014-03-04OvmfPkg: Add section of memory to use for PEI on S3 resumeJordan Justen1-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
2014-01-21OvmfPkg: Split MAINFV into a separate PEI and DXE FVsJordan Justen1-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
2014-01-21OvmfPkg: Move SEC/PEI Temporary RAM from 0x70000 to 0x810000Jordan Justen1-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
2014-01-21OvmfPkg X64 ResetVector: Move page tables from 512KB to 8MBJordan Justen1-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
2013-12-11OvmfPkg/VirtioDevice.h: Introduced VIRTIO_DEVICE_PROTOCOL protocolOlivier Martin1-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
2013-11-12OvmfPkg: indicate enablement of flash variables with a dedicated PCDLaszlo Ersek1-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
2013-11-12OvmfPkg: Add flash PCD itemsJordan Justen1-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
2012-11-02OvmfPkg: Add LoadLinuxLib library interfacejljusten1-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
2012-10-18OvmfPkg: introduce virtio-scsi driverjljusten1-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
2012-09-12OvmfPkg: extract the PBMA used in AcpiTimerLib into a PCDjljusten1-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
2012-09-12OvmfPkg: assorted whitespace removaljljusten1-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
2012-07-26OvmfPkg: add support for debug console on port 0x402jljusten1-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
2012-05-30OvmfPkg: Add QemuFwCfgLib library class and implementationjljusten1-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
2012-03-09OvmfPkg: Add PcdSecureBootEnablejljusten1-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
generated by cgit v1.1 at 2024-09-01 15:24:28 +0000