summaryrefslogtreecommitdiff
path: root/OvmfPkg/OvmfPkgIa32X64.dsc
AgeCommit message (Collapse)AuthorFilesLines
2017-11-29OvmfPkg: Add tftp dynamic commandRuiyu Ni1-2/+5
The TFTP command was converted from a NULL class library instance to a dynamic shell command in commit 0961002352e9. This patch complements commit f9bc2f876326, which only removed the old library, but didn't add the new dynamic command。 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org>
2017-11-28OvmfPkg: Fix build failure due to Tftp library removalRuiyu Ni1-1/+0
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
2017-11-17OvmfPkg: create a separate PlatformDebugLibIoPort instance for SECPaolo Bonzini1-1/+1
The next patch will want to add a global variable to PlatformDebugLibIoPort, but this is not suitable for the SEC phase, because SEC runs from read-only flash. The solution is to have two library instances, one for SEC and another for all other firmware phases. This patch adds the "plumbing" for the SEC library instance, separating the INF files and moving the constructor to a separate C source file. Contributed-under: TianoCore Contribution Agreement 1.1 Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-10-19OvmfPkg: fix dynamic default for oprom verification policy PCD without SBLaszlo Ersek1-3/+0
I missed the following, both while reviewing and while testing commit 6041ac65ae87 ("OvmfPkg/PlatformPei: DENY_EXECUTE_ON_SECURITY_VIOLATION when SEV is active", 2017-10-05): If "-D SECURE_BOOT_ENABLE" is not passed on the "build" command line, then OVMF has no dynamic default at all for "PcdOptionRomImageVerificationPolicy". This means that the PcdSet32S() call added in the subject commit doesn't even compile: > OvmfPkg/PlatformPei/AmdSev.c: In function 'AmdSevInitialize': > OvmfPkg/PlatformPei/AmdSev.c:67:3: error: implicit declaration of > function '_PCD_SET_MODE_32_S_PcdOptionRomImageVerificationPolicy' > [-Werror=implicit-function-declaration] > PcdStatus = PcdSet32S (PcdOptionRomImageVerificationPolicy, 0x4); > ^ > cc1: all warnings being treated as errors Make the current, SB-only, 0x00 dynamic default unconditional. This is the simplest approach, and it reflects the intent of original commit 1fea9ddb4e3f ("OvmfPkg: execute option ROM images regardless of Secure Boot", 2016-01-07). Without SECURE_BOOT_ENABLE, "SecurityPkg/Library/DxeImageVerificationLib" is not used anyway, so the PCD is never read. This issue was first caught and reported by Gerd Hoffmann <kraxel@redhat.com>'s Jenkins CI. Later it was also reported in <https://bugzilla.tianocore.org/show_bug.cgi?id=737>. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: 6041ac65ae879389f3ab5c0699f916d3e71c97fe Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: trim commit message as suggested by Jordan] Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [lersek@redhat.com: add reference to TianoCore BZ#737]
2017-10-17OvmfPkg/PlatformPei: DENY_EXECUTE_ON_SECURITY_VIOLATION when SEV is activeBrijesh Singh1-4/+5
The following commit: 1fea9ddb4e3f OvmfPkg: execute option ROM images regardless of Secure Boot sets the OptionRomImageVerificationPolicy to ALWAYS_EXECUTE the expansion ROMs attached to the emulated PCI devices. A expansion ROM constitute another channel through which a cloud provider (i.e hypervisor) can inject a code in guest boot flow to compromise it. When SEV is enabled, the bios code has been verified by the guest owner via the SEV guest launch sequence before its executed. When secure boot, is enabled, lets make sure that we do not allow guest bios to execute a code which is not signed by the guest owner. Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=728 Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-09-08OvmfPkg: Enable UDF file system supportPaulo Alcantara1-0/+1
This patch enables UDF file system support by default. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Paulo Alcantara <pcacjr@zytor.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
2017-07-10OvmfPkg: update PciHostBridgeDxe to use PlatformHasIoMmuLibBrijesh Singh1-0/+1
This patch enables PciHostBridgeDxe driver to use Platform IoMMU detection library to ensure that PciHostBridgeDxe is run after platform IoMmuDxe driver has checked whether platform need to install IOMMU protocol provider. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-10OvmfPkg/QemuFwCfgLib: Provide Pei and Dxe specific libraryBrijesh Singh1-1/+2
Current QemuFwCfgLib.inf is used in both Pei and Dxe phases. Add Pei and Dxe inf file to provide a seperate QemuFwCfgLib instances for Pei and Dxe phases. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 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-10OvmfPkg: Add IoMmuDxe driverBrijesh Singh1-0/+1
The IOMMU protocol driver provides capabilities to set a DMA access attribute and methods to allocate, free, map and unmap the DMA memory for the PCI Bus devices. Due to security reasons all DMA operations inside the SEV guest must be performed on shared (i.e unencrypted) pages. The IOMMU protocol driver for the SEV guest uses a bounce buffer to map guest DMA buffer to shared pages inorder to provide the support for DMA operations inside SEV guest. IoMmuDxe driver looks for SEV capabilities, if present then it installs the real IOMMU protocol otherwise it installs placeholder protocol. Currently, PciHostBridgeDxe and QemuFWCfgLib need to know the existance of IOMMU protocol. The modules needing to know the existance of IOMMU support should add gEdkiiIoMmuProtocolGuid OR gIoMmuAbsentProtocolGuid in their depex to ensure that platform IOMMU detection has been performed. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-10OvmfPkg: Add AmdSevDxe driverBrijesh Singh1-0/+1
When SEV is enabled, the MMIO memory range must be mapped as unencrypted (i.e C-bit cleared). We need to clear the C-bit for MMIO GCD entries in order to cover the ranges that were added during the PEI phase (through memory resource descriptor HOBs). Additionally, the NonExistent ranges are processed in order to cover, in advance, MMIO ranges added later in the DXE phase by various device drivers, via the appropriate DXE memory space services. The approach is not transparent for later addition of system memory ranges to the GCD memory space map. (Such ranges should be encrypted.) OVMF does not do such a thing at the moment, so this approach should be OK. The driver is being added to the APRIORI DXE file so that, we clear the C-bit from MMIO regions before any driver accesses it. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-10OvmfPkg/PlatformPei: Set memory encryption PCD when SEV is enabledBrijesh Singh1-0/+3
Secure Encrypted Virtualization (SEV) guest VMs have the concept of private and shared memory. Private memory is encrypted with the guest-specific key, while shared memory may be encrypted with hypervisor key. Certain types of memory (namely instruction pages and guest page tables) are always treated as private memory by the hardware. For data memory, SEV guest VMs can choose which pages they would like to be private. The choice is done using the standard CPU page tables using the C-bit. When building the initial page table we mark all the memory as private. The patch sets the memory encryption PCD. The PCD is consumed by the following edk2 modules, which manipulate page tables: - PEI phase modules: CapsulePei, DxeIplPeim, S3Resume2Pei. CapsulePei is not used by OVMF. DxeIplPeim consumes the PCD at the end of the PEI phase, when it builds the initial page tables for the DXE core / DXE phase. S3Resume2Pei does not consume the PCD in its entry point function, only when DxeIplPeim branches to the S3 resume path at the end of the PEI phase, and calls S3Resume2Pei's EFI_PEI_S3_RESUME2_PPI.S3RestoreConfig2() member function. Therefore it is safe to set the PCD for these modules in PlatformPei. - DXE phase modules: BootScriptExecutorDxe, CpuDxe, PiSmmCpuDxeSmm. They are all dispatched after the PEI phase, so setting the PCD for them in PlatformPei is safe. (BootScriptExecutorDxe is launched "for real" in the PEI phase during S3 resume, but it caches the PCD into a static variable when its entry point is originally invoked in DXE.) Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 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-10OvmfPkg/BaseMemcryptSevLib: Add SEV helper libraryBrijesh Singh1-0/+1
Add Secure Encrypted Virtualization (SEV) helper library. The library provides the routines to: - set or clear memory encryption bit for a given memory region. - query whether SEV is enabled. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-10OvmfPkg: Update dsc to use IoLib from BaseIoLibIntrinsicSev.infBrijesh Singh1-1/+1
When SEV is enabled then we must unroll the rep String I/O instructions. The patch updates dsc file to use SEV version of IoLib inf. The main difference between BaseIoLibIntrinsic.inf and BaseIoLibIntrinsicSev.inf is, SEV version checks if its running under SEV enabled guest, If so then it unroll the String I/O (REP INS/OUTS) otherwise fallbacks to rep ins/outs. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 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: make PcdQ35TsegMbytes dynamicLaszlo Ersek1-0/+1
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-05-23OvmfPkg: make the 4MB flash size the default (again)Laszlo Ersek1-1/+1
Xen gained support for the 4MB flash image in Xen commit 0d6968635ce5 ("hvmloader: avoid tests when they would clobber used memory", 2017-05-19), which is part of Xen 4.9.0-rc6. The previously default 2MB can be explicitly selected with -D FD_SIZE_2MB or -D FD_SIZE_IN_KB=2048 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> (cherry picked from commit bba8dfbec3bbc4fba7fa6398ba3cf76593e0725e) Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [lersek@redhat.com: reference Xen commit in commit message] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2017-05-19OvmfPkg: Add XCODE5 statements to fix build breakMichael Kinney1-0/+2
https://bugzilla.tianocore.org/show_bug.cgi?id=559 The XCODE5 tool chain has a FAMILY of GCC. The GCC statements in the [BuildOptions] section add flags that are not compatible with XCODE5. Add empty XCODE5 statements in [BuildOptions] sections to prevent the use of the GCC flags in XCODE5 builds. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Andrew Fish <afish@apple.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-05-18OvmfPkg: resolve PcdLib for PEIMs to PeiPcdLib by defaultLaszlo Ersek1-17/+5
In the previous patch we had to add two explicit Null resolutions, but here we can remove five PeiPcdLib ones, after setting the default to it. 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: resolve PcdLib for all PEIMs individuallyLaszlo Ersek1-2/+8
Currently the default (module type independent) PcdLib resolution is to BasePcdLibNull.inf, which is inherited by all PEIMs. In the next patch, we'll flip the PEIM default resolution to PeiPcdLib.inf, but in order to keep that patch both correct and simple to review, we should spell out the Null resolution for those two PEIMs (ReportStatusCodeRouterPei and StatusCodeHandlerPei) that are now the only ones that don't specify an explicit resolution. 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/PlatformPei: don't allocate reserved mem varstore if SMM_REQUIRELaszlo Ersek1-0/+3
For the emulated variable store, PlatformPei allocates reserved memory (as early as possible, so that the address remains the same during reboot), and PcdEmuVariableNvStoreReserved carries the address to EmuVariableFvbRuntimeDxe. However, EmuVariableFvbRuntimeDxe is excluded from the SMM_REQUIRE build, and then noone consumes PcdEmuVariableNvStoreReserved. Don't waste reserved memory whenever that's the case. (Even a dynamic default for PcdEmuVariableNvStoreReserved would be unnecessary; but that way the PcdSet64S() call in the ReserveEmuVariableNvStore() function doesn't compile.) 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: sync PcdVariableStoreSize with PcdFlashNvStorageVariableSizeLaszlo Ersek1-1/+2
"MdeModulePkg/MdeModulePkg.dec" declares PcdVariableStoreSize like this: > The size of volatile buffer. This buffer is used to store VOLATILE > attribute variables. There is no inherent reason why the size of the volatile variable store should match the same of the non-volatile variable store. Indeed flash variables in the 4MB build work fine without this equality. However, OvmfPkg/EmuVariableFvbRuntimeDxe uses PcdVariableStoreSize to initialize the non-volatile VARIABLE_STORE_HEADER too. (Presumably based on the fact that ultimately that storage will not be permanent.) When using EmuVariableFvbRuntimeDxe in the 4MB build, the mismatch between the two mentioned PCDs (which is apparent through EmuVariableFvbRuntimeDxe's VARIABLE_STORE_HEADER) triggers an assertion in the variable driver: > ASSERT MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c(3772): > mNvVariableCache->Size == VariableStoreLength Bringing PcdVariableStoreSize in sync with PcdFlashNvStorageVariableSize fixes this. It also happens to ensure a volatile store size in the 4MB build that equals the non-volatile store size, which likely doesn't hurt for symmetry. Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: b24fca05751f8222acf264853709012e0ab7bf49 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-3/+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-05-05Revert "OvmfPkg: make the 4MB flash size the default"Laszlo Ersek1-1/+1
This reverts commit bba8dfbec3bbc4fba7fa6398ba3cf76593e0725e. The 264KB size introduced for the NV spare area in commit b24fca05751f ("OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK", 2017-04-29) breaks the "-bios" (emulated varstore) use case. Until we sort that out, revert the default build to the 2MB image. 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-05-05OvmfPkg: make the 4MB flash size the defaultLaszlo Ersek1-1/+1
The previously default 2MB can be explicitly selected with -D FD_SIZE_2MB or -D FD_SIZE_IN_KB=2048 Cc: Gary Ching-Pang Lin <glin@suse.com> 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-05-05OvmfPkg: raise max variable size (auth & non-auth) to 33KB for FD_SIZE_4MBLaszlo Ersek1-0/+6
The "ConfirmSetOfLargeVariable" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit sets a 32 KB large non-authenticated variable. In the FD_SIZE_4MB build, our live varstore is now 256 KB big, so we can accommodate this. Set both PcdMaxVariableSize and PcdMaxAuthVariableSize to 0x8400 -- beyond DataSize=0x8000 from the HCK test, we need some room for the variable name and attributes as well. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-05OvmfPkg: introduce 4MB flash image (mainly) for Windows HCKLaszlo Ersek1-0/+4
The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-05OvmfPkg: introduce the FD_SIZE_IN_KB macro / build flagLaszlo Ersek1-0/+15
FD_SIZE_xMB defines have existed for flash size selection. They can be passed as "-D FD_SIZE_xMB" on the command line. Passing multiple of them at the same time has never been supported; earlier settings on the command line cannot be overridden. Introduce the integer valued FD_SIZE_IN_KB macro, which provides the following improvements: - several instances of it are permitted on the command line, with the last one taking effect, - conditional statements in the DSC and FDF files need only check a single macro, and multiple values can be checked in a single !if with the || operator, - nested !ifdef / !else ladders can be replaced with flat equality tests, - in the future, flash sizes can be expressed with a finer than MB granularity, if necessary. For now, we're going to preserve the FD_SIZE_xMB defines as convenience wrappers for FD_SIZE_IN_KB. FD_SIZE_IN_KB is being added to the DSC files because this way we can depend on it in both the DSC and FDF files. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-03-14OvmfPkg: resolve QemuFwCfgS3LibLaszlo Ersek1-0/+3
QemuFwCfgS3Enabled() in "OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c" queries the "etc/system-states" fw_cfg file. The same implementation is now available factored-out in "OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3PeiDxe.c". It is available to PEIMs through the PeiQemuFwCfgS3LibFwCfg instance, and to DXE_DRIVER and DXE_RUNTIME_DRIVER modules through the DxeQemuFwCfgS3LibFwCfg instance. Resolve QemuFwCfgS3Lib accordingly. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 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-02-25OvmfPkg: exclude libssl functionality from OpensslLib if TLS_ENABLE=FALSELaszlo Ersek1-0/+4
The OpensslLibCrypto library instance (which does not contain libssl functions) is sufficient for the Secure Boot feature. Ease security analysis by excluding libssl functionality from the OpensslLib instance we use with TLS_ENABLE=FALSE. Cc: Gary Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com>
2017-02-07OvmfPkg: dynamic defaults for PcdCpuSmmApSyncTimeout, PcdCpuSmmSyncModeLaszlo Ersek1-2/+5
Move the platform-specific default values for these PCDs from the [PcdsFixedAtBuild] / [PcdsFixedAtBuild.X64] sections to the [PcdsDynamicDefault] section. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=230 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-01-23OvmfPkg: Allow HTTP connections if HTTP Boot enabledJiaxin Wu1-1/+5
v2 * Move the setting above the "!ifndef $(USE_OLD_SHELL)" part. * Un-indent the setting to column zero. (Comments from Laszlo) Overwrite the value of PcdAllowHttpConnections to allow HTTP connections if HTTP Boot enabled (-D HTTP_BOOT_ENABLE). Cc: Laszlo Ersek <lersek@redhat.com> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Kinney Michael D <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com>
2017-01-17OvmfPkg: pull in TLS modules with -D TLS_ENABLE (also enabling HTTPS)Gary Lin1-0/+9
This commit introduces a new build option, TLS_ENABLE, to pull in the TLS-related modules. If HTTP_BOOT_ENABLE and TLS_ENABLE are enabled at the same time, the HTTP driver locates the TLS protocols automatically and thus HTTPS is enabled. To build OVMF with HTTP Boot: $ ./build.sh -D HTTP_BOOT_ENABLE To build OVMF with HTTPS Boot: $ ./build.sh -D HTTP_BOOT_ENABLE -D TLS_ENABLE Cc: Laszlo Ersek <lersek@redhat.com> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Long Qin <qin.long@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-01-17OvmfPkg: correct the IScsiDxe module included for the IPv6 stackGary Lin1-7/+4
Always use IScsiDxe from NetworkPkg when IPv6 is enabled since it provides the complete ISCSI support. NOTE: This makes OpenSSL a hard requirement when NETWORK_IP6_ENABLE is true. (Based on Jiaxin's suggestion) Cc: Laszlo Ersek <lersek@redhat.com> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Long Qin <qin.long@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: update subject line] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2017-01-17OvmfPkg: always resolve OpenSslLib, IntrinsicLib and BaseCryptLibGary Lin1-6/+3
This commit provides unconditional library resolutions for the OpenSslLib, IntrinsicLib and BaseCryptLib classes, regardless of whether those classes are actually used by any module. Although those libraries depends on OpenSSL, they won't be built unless a module really uses them. Thus, missing OpenSSL from the tree won't cause any build failure as long as SECURE_BOOT_ENABLE is false. (Based on Jiaxin's patch and Laszlo's suggestion) Cc: Laszlo Ersek <lersek@redhat.com> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Long Qin <qin.long@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-01-06OvmfPkg: Install BGRT ACPI tableBhupesh Sharma1-0/+1
While debugging OS for ACPI BGRT support (especially on VMs), it is very useful to have the EFI firmware (OVMF in most cases which use Tianocore) to export the ACPI BGRT table. This patch tries to add this support in OvmfPkg. Tested this patch in the following environments: 1. On both RHEL7.3 and Fedora-25 VM guests running on a Fedora-24 Host: - Ensured that the BGRT logo is properly prepared and can be viewed with user-space tools (like 'Gwenview' on KDE, for example): $ file /sys/firmware/acpi/bgrt/image /sys/firmware/acpi/bgrt/image: PC bitmap, Windows 3.x format, 193 x 58 x 24 2. On a Windows-10 VM Guest running on a Fedora-24 Host: - Ensured that the BGRT ACPI table is properly prepared and can be read with freeware tool like FirmwareTablesView: ================================================== Signature : BGRT Firmware Provider : ACPI Length : 56 Revision : 1 Checksum : 129 OEM ID : INTEL OEM Table ID : EDK2 OEM Revision : 0x00000002 Creator ID : 0x20202020 Creator Revision : 0x01000013 Description : ================================================== Note from Laszlo Ersek <lersek@redhat.com>: without the BGRT ACPI table, Windows 8 and Windows 10 first clear the screen, then display a blue, slanted Windows picture above the rotating white boot animation. With the BGRT ACPI table, Windows 8 and Windows 10 don't clear the screen, the blue Windows image is not displayed, and the rotating white boot animation is shown between the firmware's original TianoCore boot splash and (optional) "Start boot option" progress bar. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: cover effect on Windows 8/10 boot anim. in commit msg] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2016-12-02OvmfPkg: Remove use of IntelFrameworkModulePkg legacy libsLeif Lindholm1-2/+2
LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied from IntelFrameworkModulePkg to MdeModulePkg, but the originals were kept for compatibility. Since the libraries are identical, move OvmfPkg to use the MdeModulePkg versions instead. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-11-29OvmfPkg/PlatformPei: take VCPU count from QEMU and configure MpInitLibLaszlo Ersek1-0/+4
These settings will allow CpuMpPei and CpuDxe to wait for the initial AP check-ins exactly as long as necessary. It is safe to set PcdCpuMaxLogicalProcessorNumber and PcdCpuApInitTimeOutInMicroSeconds in OvmfPkg/PlatformPei. OvmfPkg/PlatformPei installs the permanent PEI RAM, producing gEfiPeiMemoryDiscoveredPpiGuid, and UefiCpuPkg/CpuMpPei has a depex on gEfiPeiMemoryDiscoveredPpiGuid. It is safe to read the fw_cfg item QemuFwCfgItemSmpCpuCount (0x0005). It was added to QEMU in 2008 as key FW_CFG_NB_CPUS, in commit 905fdcb5264c ("Add common keys to firmware configuration"). Even if the key is unavailable (or if fw_cfg is entirely unavailable, for example on Xen), QemuFwCfgRead16() will return 0, and then we stick with the current behavior. Cc: Igor Mammedov <imammedo@redhat.com> 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: Jordan Justen <jordan.l.justen@intel.com>
2016-11-18OvmfPkg: Add 4K PE alignment to enable SMM page level protection.Jiewen Yao1-0/+5
Tested boot with below configuration: IA32 IA32X64 X64 Tested boot with XD enabled/disabled. Requested-by: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2016-10-25OvmfPkg: disable deprecated interfacesLaszlo Ersek1-0/+7
At this point no code in OvmfPkg (and apparently no code outside of OvmfPkg that OVMF depends on) uses the deprecated APIs, so we can disable them in the platform DSC files: BaseLib: - StrCpy - StrnCpy - StrCat - StrnCat - UnicodeStrToAsciiStr - AsciiStrCpy - AsciiStrnCpy - AsciiStrCat - AsciiStrnCat - AsciiStrToUnicodeStr PcdLib: - PcdSet8 - PcdSet16 - PcdSet32 - PcdSet64 - PcdSetPtr - PcdSetBool - PcdSetEx8 - PcdSetEx16 - PcdSetEx32 - PcdSetEx64 - PcdSetExPtr - PcdSetExBool UefiLib: - GetVariable - GetEfiGlobalVariable 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-10-12OvmfPkg: add NOOPT build target for source level debuggingBruce Cran1-1/+1
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Bruce Cran <bruce.cran@sandisk.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: beautify subject line] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2016-10-12OvmfPkg: Remove unused BltLib referenceRuiyu Ni1-4/+1
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek at redhat.com>
2016-10-12OvmfPkg: Include MdeModulePkg/FrameBufferLib in OvmfPkgRuiyu Ni1-0/+1
One of the following patches will change QemuVideoDxe driver to use the new FrameBufferLib. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek at redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com>
2016-09-28OvmfPkg: Use the new LogoDxe driverRuiyu Ni1-2/+1
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
2016-09-02OvmfPkg: Use MdeModulePkg/ResetSystemRuntimeDxeRuiyu Ni1-1/+1
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
2016-09-01OvmfPkg: include VirtioGpuDxe in the platform DSC/FDF filesLaszlo Ersek1-0/+1
At this stage, the driver builds, and suffices for testing binding and unbinding. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66 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-08-17OvmfPkg: Add MpInitLib reference in DSC files.Jeff Fan1-0/+2
This update is for CpuMpPei&CpuDxe consuming MP Initialize library. Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2016-08-02OvmfPkg: use StatusCode Router and Handler from MdeModulePkgCinnamon Shia1-2/+5
In the Platform Init v1.4a spec, - Volume 1 "4.7 Status Code Service" defines the EFI_PEI_SERVICES.ReportStatusCode() service, - Volume 1 "6.3.5 Status Code PPI (Optional)" defines the EFI_PEI_PROGRESS_CODE_PPI (equivalent to the above), - Volume 2 "14.2 Status Code Runtime Protocol" defines the EFI_STATUS_CODE_PROTOCOL. These allow PEIMs and DXE (and later) modules to report status codes. Currently OvmfPkg uses modules from under "IntelFrameworkModulePkg/Universal/StatusCode/", which produce the above abstractions (PPI and PROTOCOL) directly, and write the status codes, as they are reported, to the serial port or to a memory buffer. This is called "handling" the status codes. In the Platform Init v1.4a spec, - Volume 3 "7.2.2 Report Status Code Handler PPI" defines EFI_PEI_RSC_HANDLER_PPI, - Volume 3 "7.2.1 Report Status Code Handler Protocol" defines EFI_RSC_HANDLER_PROTOCOL. These allow several PEIMs and runtime DXE drivers to register callbacks for status code handling. MdeModulePkg offers a PEIM under "MdeModulePkg/Universal/ReportStatusCodeRouter/Pei" that produces both EFI_PEI_PROGRESS_CODE_PPI and EFI_PEI_RSC_HANDLER_PPI, and a runtime DXE driver under "MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe" that produces both EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL. MdeModulePkg also offers status code handler modules under MdeModulePkg/Universal/StatusCodeHandler/ that depend on EFI_PEI_RSC_HANDLER_PPI and EFI_RSC_HANDLER_PROTOCOL, respectively. The StatusCodeHandler modules register themselves with ReportStatusCodeRouter through EFI_PEI_RSC_HANDLER_PPI / EFI_RSC_HANDLER_PROTOCOL. When another module reports a status code through EFI_PEI_PROGRESS_CODE_PPI / EFI_STATUS_CODE_PROTOCOL, it reaches the phase-matching ReportStatusCodeRouter module first, which in turn passes the status code to the pre-registered, phase-matching StatusCodeHandler module. The status code handling in the StatusCodeHandler modules is identical to the one currently provided by the IntelFrameworkModulePkg modules. Replace the IntelFrameworkModulePkg modules with the MdeModulePkg ones, so we can decrease our dependency on IntelFrameworkModulePkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com> Suggested-by: Liming Gao <liming.gao@intel.com> Fixes: https://tianocore.acgmultimedia.com/show_bug.cgi?id=63 [jordan.l.justen@intel.com: point out IntelFareworkModulePkg typos] Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [lersek@redhat.com: rewrap to 74 cols; fix IntelFareworkModulePkg typos] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2016-07-15OvmfPkg: include UefiCpuPkg/CpuMpPeiLaszlo Ersek1-0/+5
In the next patch we're going to put EFI_PEI_MP_SERVICES_PPI to use. CpuMpPei uses the following PCDs from gUefiCpuPkgTokenSpaceGuid, beyond those already used by CpuDxe: - PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize: these control whether CpuMpPei performs microcode update. If the region size is zero, then the microcode update is skipped. UefiCpuPkg.dec sets the region size to zero by default, which is appropriate for OVMF. - PcdCpuApLoopMode and PcdCpuApTargetCstate: the former controls how CpuMpPei puts the APs to sleep: 1 -- HLT, 2 -- MWAIT, 3 -- busy wait (with PAUSE). The latter PCD is only relevant if the former PCD is 2 (MWAIT). In order to be consistent with SeaBIOS and with CpuDxe itself, we choose HLT. That's the default set by UefiCpuPkg.dec. Furthermore, although CpuMpPei could consume SecPeiCpuExceptionHandlerLib technically, it is supposed to consume PeiCpuExceptionHandlerLib. See: - http://thread.gmane.org/gmane.comp.bios.edk2.devel/12703 - git commit a81abf161666 ("UefiCpuPkg/ExceptionLib: Import PeiCpuExceptionHandlerLib module"), part of the series linked above. Jeff recommended to resolve CpuExceptionHandlerLib to PeiCpuExceptionHandlerLib for all PEIMs: - http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471/focus=14477 Since at the moment we have no resolution in place that would cover this for PEIMs (from either [LibraryClasses] or [LibraryClasses.common.PEIM]), it's easy to do. 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-07-13OvmfPkg: add PciHotPlugInitDxeLaszlo Ersek1-0/+1
After IncompatiblePciDeviceSupportDxe, this is another small driver / protocol implementation that tweaks the behavior of the PCI bus driver in edk2. The protocol is specified in the Platform Init Spec v1.4a, Volume 5, Chapter 12.6 "PCI Hot Plug PCI Initialization Protocol". This implementation steers the PCI bus driver to reserve the following resources ("padding") for each PCI bus, in addition to the BARs of the devices on that PCI bus: - 2MB of 64-bit non-prefetchable MMIO aperture, - 512B of IO port space. The goal is to reserve room for devices hot-plugged at runtime even if the bridge receiving the device is empty at boot time. The 2MB MMIO size is inspired by SeaBIOS. The 512B IO port size is actually only 1/8th of the PCI spec mandated reservation, but the specified size of 4096 has proved wasteful (given the limited size of our IO port space -- see commit bba734ab4c7c). Especially on Q35, where every PCIe root port and downstream port qualifies as a separate bridge (capable of accepting a single device). Test results for this patch: - regardless of our request for 64-bit MMIO reservation, it is downgraded to 32-bit, - although we request 512B alignment for the IO port space reservation, the next upstream bridge rounds it up to 4096B. Cc: "Johnson, Brian J." <bjohnson@sgi.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Andrew Fish <afish@apple.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Suggested-by: Andrew Fish <afish@apple.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
2016-06-28OvmfPkg: Re-add the Driver Health ManagerBruce Cran1-0/+1
The Driver Health HII menu is not an integral part of the MdeModulePkg BDS driver / UI app. Because we abandoned the IntelFrameworkModulePkg BDS, now we have to get the same functionality explicitly from DriverHealthManagerDxe. Suggested-by: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bruce Cran <bruce.cran@gmail.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: update commit message] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2016-06-06OvmfPkg: set SMM stack size to 16KBLaszlo Ersek1-0/+1
The default stack size (from UefiCpuPkg/UefiCpuPkg.dec) is 8KB, which proved too small (i.e., led to stack overflow) across commit range 98c2d9610506^..f85d3ce2efc2^, during certificate enrollment into "db". As the edk2 codebase progresses and OVMF keeps including features, the stack demand constantly fluctuates; double the SMM stack size for good measure. Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/12864 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1341733 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
generated by cgit v1.1 at 2024-09-08 11:36:15 +0000