summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/OvmfPkgIa32.dsc
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: exclude libssl functionality from OpensslLib if TLS_ENABLE=FALSELaszlo Ersek2017-02-251-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>
* OvmfPkg: dynamic defaults for PcdCpuSmmApSyncTimeout, PcdCpuSmmSyncModeLaszlo Ersek2017-02-071-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>
* OvmfPkg: Allow HTTP connections if HTTP Boot enabledJiaxin Wu2017-01-231-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>
* OvmfPkg: pull in TLS modules with -D TLS_ENABLE (also enabling HTTPS)Gary Lin2017-01-171-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>
* OvmfPkg: correct the IScsiDxe module included for the IPv6 stackGary Lin2017-01-171-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>
* OvmfPkg: always resolve OpenSslLib, IntrinsicLib and BaseCryptLibGary Lin2017-01-171-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>
* OvmfPkg: Install BGRT ACPI tableBhupesh Sharma2017-01-061-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>
* OvmfPkg: Remove use of IntelFrameworkModulePkg legacy libsLeif Lindholm2016-12-021-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>
* OvmfPkg/PlatformPei: take VCPU count from QEMU and configure MpInitLibLaszlo Ersek2016-11-291-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>
* OvmfPkg: Add 4K PE alignment to enable SMM page level protection.Jiewen Yao2016-11-181-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>
* OvmfPkg: disable deprecated interfacesLaszlo Ersek2016-10-251-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>
* OvmfPkg: add NOOPT build target for source level debuggingBruce Cran2016-10-121-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>
* OvmfPkg: Remove unused BltLib referenceRuiyu Ni2016-10-121-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>
* OvmfPkg: Include MdeModulePkg/FrameBufferLib in OvmfPkgRuiyu Ni2016-10-121-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>
* OvmfPkg: Use the new LogoDxe driverRuiyu Ni2016-09-281-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>
* OvmfPkg: Use MdeModulePkg/ResetSystemRuntimeDxeRuiyu Ni2016-09-021-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>
* OvmfPkg: include VirtioGpuDxe in the platform DSC/FDF filesLaszlo Ersek2016-09-011-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>
* OvmfPkg: Add MpInitLib reference in DSC files.Jeff Fan2016-08-171-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>
* OvmfPkg: use StatusCode Router and Handler from MdeModulePkgCinnamon Shia2016-08-021-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>
* OvmfPkg: include UefiCpuPkg/CpuMpPeiLaszlo Ersek2016-07-151-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>
* OvmfPkg: add PciHotPlugInitDxeLaszlo Ersek2016-07-131-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>
* OvmfPkg: Re-add the Driver Health ManagerBruce Cran2016-06-281-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>
* OvmfPkg: set SMM stack size to 16KBLaszlo Ersek2016-06-061-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>
* OvmfPkg/PlatformBootManagerLib: rebase boot logo display to BootLogoLibLaszlo Ersek2016-05-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the course of porting OvmfPkg to the MdeModulePkg BDS, commit 817fb3ac2a78 OvmfPkg/PlatformBootManagerLib: Add EnableQuietBoot & DisableQuietBoot open-coded the EnableQuietBoot() function (and its dependencies / friends) from IntelFrameworkModulePkg BDS. This code duplication can be avoided; the functionality is available from the following three libraries in MdeModulePkg: - BootLogoLib: provides the BootLogoEnableLogo() function. It does not provide the internal ConvertBmpToGopBlt() function -- that one is delegated to ImageDecoderLib (function DecodeImage()). - ImageDecoderLib: a general library that registers decoder plugins for specific image formats, and provides the generic DecodeImage() on top. - BmpImageDecoderLib: one of said decoder plugins, for handling BMP images (which is the format of our logo). In this patch, we revert 817fb3ac2a78, and atomically incorporate the above libraries. This is inspired by Nt32Pkg commit 859e75c4fc42: Nt32Pkg: Use BootLogoLib for logo and progress bar drawing. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSMLaszlo Ersek2016-05-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to edk2 commit "MdeModulePkg/PciBus: do not improperly degrade resource" and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the Platform Init 1.4a specification, a platform can provide such a protocol in order to influence the PCI resource allocation performed by the PCI Bus driver. In particular it is possible instruct the PCI Bus driver, with a "wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit address space, regardless of whether the device features an option ROM. (By default, the PCI Bus driver considers an option ROM reason enough for allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS binary from a combined option ROM could be dispatched, and fail to access MMIO BARs in 64-bit address space.) In platform code we can ascertain whether a CSM is present or not. If not, then legacy BIOS binaries in option ROMs can't be dispatched, hence the BAR degradation is detrimental, and we should prevent it. This is expected to conserve the 32-bit address space for 32-bit MMIO BARs. The driver added in this patch could be simplified based on the following facts: - In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence the driver will exit immediately. Therefore the driver could be omitted from the Ia32 build. - In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE was defined (because in that case the degradation would be justified). On the other hand, if CSM_ENABLE was undefined, then the driver could be included, and it could provide the hint unconditionally (without looking for the Legacy BIOS protocol). These short-cuts are not taken because they would increase the differences between the OVMF DSC/FDF files. If we can manage without extreme complexity, we should use dynamic logic (vs. build time configuration), plus keep conditional compilation to a minimum. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg, ArmVirtPkg: rename QemuNewBootOrderLib to QemuBootOrderLibLaszlo Ersek2016-05-251-1/+1
| | | | | | | | | | | | | | | This completes the transition to the new BDS. The FILE_GUID in "QemuBootOrderLib.inf" is intentionally not changed. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: remove USE_OLD_BDS build fallback macroLaszlo Ersek2016-05-251-19/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reasons: - USE_OLD_BDS requires duplicating updates between OVMF's library instances that depend on USE_OLD_BDS being FALSE vs. TRUE. Examples: d5aee61bfaaa OvmfPkg/QemuNewBootOrderLib: adapt Q35 SATA PMPN to UEFI spec Mantis 1353 1da761664949 OvmfPkg/QemuBootOrderLib: adapt Q35 SATA PMPN to UEFI spec Mantis 1353 - The Xen community has embraced the new BDS. Examples: 14b2ebc30c8b OvmfPkg/PlatformBootManagerLib: Postpone the shell registration 49effaf26ec9 OvmfPkg/PciHostBridgeLib: Scan for root bridges when running over Xen - OVMF doesn't build with "-D USE_OLD_BDS -D HTTP_BOOT_ENABLE" anyway, as NetworkPkg/HttpBootDxe now requires UefiBootManagerLib: 50a65824c74a NetworkPkg: Use UefiBootManagerLib API to create load option. We (correctly) don't resolve UefiBootManagerLib when USE_OLD_BDS is TRUE. - The new BDS has been working well; for example it's the only BDS available in ArmVirtPkg: 1946faa710e6 ArmVirtPkg/ArmVirtQemu: use MdeModulePkg/BDS Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/PlatformPei: set PCI IO port aperture dynamicallyLaszlo Ersek2016-05-171-0/+2
| | | | | | | | | | | | | | | | | | 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>
* OvmfPkg: Modify FDF/DSC files for RamDiskDxe's adding NFIT report featureHao Wu2016-05-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The RamDiskDxe driver in MdeModulePkg now will use EFI_ACPI_TABLE_PROTOCOL and EFI_ACPI_SDT_PROTOCOL during reporting RAM disks to NVDIMM Firmware Interface Table (NFIT). A Pcd 'PcdInstallAcpiSdtProtocol' controls whether the EFI_ACPI_SDT_PROTOCOL will be produced. Its default value is set to FALSE in MdeModulePkg. To make the NFIT reporting feature working properly under OVMF, the patch will set the Pcd to TRUE in OVMF DSC files. Also, the RamDiskDxe driver will sometimes report a NVDIMM Root Device using ASL code which is put in a Secondary System Description Table (SSDT) according to the ACPI 6.1 spec. Locating the SSDT requires modifying the [Rule.Common.DXE_DRIVER] field in OVMF FDF files. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Samer El-Haj-Mahmoud <elhaj@hpe.com>
* OvmfPkg: Use MdeModulePkg/BDSRuiyu Ni2016-05-041-4/+37
| | | | | | | | | | | | By default the new MdeModulePkg/BDS is used. If USE_OLD_BDS is defined to TRUE, IntelFrameworkModulePkg/BDS is used. Fixes: https://github.com/tianocore/edk2/issues/62 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: remove USE_OLD_PCI_HOST build optionLaszlo Ersek2016-04-071-19/+0
| | | | | | | | | | | | | | | | | | It's been a month since the following commits appeared in the repo: 4014885ffdfa8 OvmfPkg: switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe c47ed6fcb5e60 OvmfPkg: match PCI config access to machine type (if not USE_OLD_PCI_HOST) in which we introduced the USE_OLD_PCI_HOST fallback, and made other work depend on it. I have not heard of any problems (primarily from the vfio-users group that uses Gerd's daily / hourly OVMF builds), so it's time to drop the fallback. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Convert to using FatPkg in the EDK II treeJordan Justen2016-04-071-0/+1
| | | | | | | | | | | | | Now that FatPkg is open source (and therefore can be included in the EDK II tree) we build and use it directly. Build tested with GCC 5.3 on IA32 and X64. Boot tested to UEFI Shell on IA32 and UEFI Linux on X64. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Retire AcpiS3SaveDxeStar Zeng2016-04-071-1/+0
| | | | | | | | | | | | | The same functional code has been in S3SaveStateDxe, OVMF AcpiS3SaveDxe can be retired now. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Set PcdAcpiS3Enable according to QemuFwCfgS3Enabled()Star Zeng2016-04-071-0/+1
| | | | | | | | | | | | Also need to declare PcdAcpiS3Enable as DynamicDefault in *.dsc. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: disable PcdHiiOsRuntimeSupportLaszlo Ersek2016-04-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Edk2 commit 8a45f80edad4 ("MdeModulePkg: Make HII configuration settings available to OS runtime") implements the optional UEFI feature described in "31.2.11.1 OS Runtime Utilization" in UEFI v2.6. While this feature might show benefits down the road even in QEMU virtual machines, at the moment it only presents drawbacks: - it increases the EfiRuntimeServicesData footprint, - it triggers HII compatibility problems between edk2 and external drivers unconditionally, even if the end-user is not interested in HII and/or in configuring said drivers (see <https://www.redhat.com/archives/vfio-users/2016-March/msg00153.html> and <http://thread.gmane.org/gmane.comp.bios.edk2.devel/9894> for an example). While the feature was being introduced, popular demand for a controlling Feature PCD rose (see <http://thread.gmane.org/gmane.comp.bios.edk2.devel/7626>), which is why we can set it now to FALSE. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: remove PcdMaxHardwareErrorVariableSize from the DSC filesLaszlo Ersek2016-04-061-1/+0
| | | | | | | | | | | | | | | | | | | | | | PcdMaxHardwareErrorVariableSize sets the size limit for individual Hardware Error Record Variables (see "7.2.3 Hardware Error Record Persistence" and "Appendix P, Hardware Error Record Persistence Usage" in the UEFI-2.6 spec). Since Hardware Error Record Persistence is an optional firmware feature, according to the spec, and OVMF does not enable it -- it inherits PcdHwErrStorageSize and PcdHardwareErrorRecordLevel with zero values --, the PcdMaxHardwareErrorVariableSize setting in our DSC files has no effect. Remove it in order to eliminate future confusion. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Star Zeng <star.zeng@intel.com> Suggested-by: Star Zeng <star.zeng@intel.com> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/9743/focus=9780 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: include Virtio10DxeLaszlo Ersek2016-04-061-0/+1
| | | | | | | | Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Add RAM disk supportAlcantara, Paulo2016-04-011-2/+1
| | | | | | | | | | | | | | | Currently booting off of a RAM disk is not supported by IntelFrameWorkModulePkg BDS, however on systems without writable disks, the RAM disk can be made useful when loading raw HDD images into it -- specially the ones with a FAT32 partition on which files can be natively accessed by system firmware. This patch adds RamDiskDxe driver by default in OVMF platform. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paulo Alcantara <paulo.alc.cavalcanti@hp.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Increase the maximum size for Authenticated variablesJames Bottomley2016-03-251-0/+1
| | | | | | | | | | | | | | | | | During real world testing I was getting an error with too many entries in db: On my Secure boot laptop, I currently have seven certificates: two Microsoft ones, Three Kernel ones from various distributions, my own Secure Key and a temporary test key. That gives a total EFI Signature List size of 8317 which is over the 0x2000 maximum. Fix this by setting the PcdMaxAuthVariableSize to 0x2800 (10K) which isn't much of an increase but allows for 9-10 certificates. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* OvmfPkg: match PCI config access to machine type (if not USE_OLD_PCI_HOST)Laszlo Ersek2016-03-101-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If USE_OLD_PCI_HOST is FALSE, then we switch all executable module types supported by DxePciLibI440FxQ35 to the following library instance stack: BasePciSegmentLibPci [class: PciSegmentLib] DxePciLibI440FxQ35 [class: PciLib] BasePciCf8Lib [class: PciCf8Lib] BasePciExpressLib [class: PciExpressLib] Every module will select 0xCF8 vs. ECAM based on the OVMF platform type (i440fx or Q35). Notably, MdeModulePkg/Bus/Pci/PciHostBridgeDxe is among the affected drivers. The BasePciExpressLib instance is where the PcdPciExpressBaseAddress PCD fills its original role. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Michał Zegan <webczat_200@poczta.onet.pl> 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> Tested-by: Michał Zegan <webczat_200@poczta.onet.pl>
* OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35Laszlo Ersek2016-03-101-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The comments in the code should speak for themselves; here we note only two facts: - The PCI config space writes (to the PCIEXBAR register) are performed using the 0xCF8 / 0xCFC IO ports, by virtue of PciLib being resolved to BasePciLibCf8. (This library resolution will permanently remain in place for the PEI phase.) - Since PCIEXBAR counts as a chipset register, it is the responsibility of the firmware to reprogram it at S3 resume. Therefore PciExBarInitialization() is called regardless of the boot path. (Marcel recently posted patches for SeaBIOS that implement this.) This patch suffices to enable PCIEXBAR (and the dependent ACPI table generation in QEMU), for the sake of "PCIeHotplug" in the Linux guest: ACPI: MCFG 0x000000007E17F000 00003C (v01 BOCHS BXPCMCFG 00000001 BXPC 00000001) PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820 acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability] In the following patches, we'll equip the core PCI host bridge / root bridge driver and the rest of DXE as well to utilize ECAM on Q35. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Michał Zegan <webczat_200@poczta.onet.pl> Ref: https://github.com/tianocore/edk2/issues/32 Ref: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/10548 Suggested-by: Marcel Apfelbaum <marcel@redhat.com> Reported-by: Michał Zegan <webczat_200@poczta.onet.pl> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Michał Zegan <webczat_200@poczta.onet.pl> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Enable Network2 Shell Commands for IPv6Gary Lin2016-03-081-0/+3
| | | | | | | | | | Enable the network2 commands when NETWORK_IP6_ENABLE is TRUE, so we would have Ping6 and Ifconfig6. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Ching-Pang Lin <glin@suse.com> [lersek@redhat.com: added the word "Shell" to the subject] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxeLaszlo Ersek2016-03-031-0/+8
| | | | | | | | | | | | | | | | | | | | | The old driver is retained for now; it remains available with "-D USE_OLD_PCI_HOST". This is because I'd like to involve end users and downstreams in testing the new drier, but also allow them to switch back to the old driver at the first sight of trouble, while we debug the new driver in parallel. In a few weeks the ifdeffery and the "OvmfPkg/PciHostBridgeDxe/" driver should be removed. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: resolve PciSegmentLibLaszlo Ersek2016-03-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the next patch we'll build "MdeModulePkg/Bus/Pci/PciHostBridgeDxe". That driver depends on the PciSegmentLib class. Edk2 offers four instances: (1) MdePkg/Library/UefiPciSegmentLibPciRootBridgeIo/ Inappropriate here because it consumes EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL, but "MdeModulePkg/Bus/Pci/PciHostBridgeDxe" needs the library class for producing that protocol. (2) MdePkg/Library/PeiPciSegmentLibPciCfg2/ Restricted to PEIM, SEC, and PEI_CORE client modules. (3) MdePkg/Library/DxePciSegmentLibEsal/ "uses ESAL services to perform PCI Configuration cycles" (4) MdePkg/Library/BasePciSegmentLibPci/ A simple BASE library instance that sits on top of PciLib. This is our choice. We can resolve PciSegmentLib to this instance for all module types. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: factor the MMIO aperture shared by all PCI root bridges into PCDsLaszlo Ersek2016-03-031-0/+2
| | | | | | | | | | | | | | | | | Going forward, two modules will need to know about the aperture: PlatformPei (as before), and OVMF's upcoming PciHostBridgeLib instance (because the core PciHostBridgeDxe driver requires the library to state the exact apertures for all root bridges). On QEMU, all root bridges share the same MMIO aperture, hence one pair of PCDs suffices. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: copy log level comments from DebugLib.hLaszlo Ersek2016-03-021-0/+22
| | | | | | | | 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: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Add FileExplorerLib.inf to the dsc fileDandan Bi2016-02-261-1/+4
| | | | | | | | | | | | | | | Because SecureBootConfigDxe use FileExplorerLib now, but FileExplorerLib is not in the dsc file of the package that use SecureBootConfigDxe. Now add it to pass build. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: add driver for Virtio-RNG deviceArd Biesheuvel2016-02-241-0/+1
| | | | | | | | | | | This adds the new Virtio-RNG DXE module to all three builds of OvmfPkg. Note that QEMU needs to be invoked with the 'device virtio-rng-pci' option in order for this device to be exposed to the guest. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: include NvmExpressDxe driverLaszlo Ersek2016-02-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | QEMU emulates NVMe. NvmExpressDxe seems to work well with it. The relevant QEMU options are -drive id=drive0,if=none,format=FORMAT,file=PATHNAME \ -device nvme,drive=drive0,serial=SERIAL where the required SERIAL value sets the Serial Number (SN) field of the "Identify Controller Data Structure". It is an ASCII string with up to 20 characters, which QEMU pads with spaces to maximum length. (Refer to "NVME_ADMIN_CONTROLLER_DATA.Sn" in "MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.h".) Cc: Vladislav Vovchenko <vladislav.vovchenko@sk.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reference: https://github.com/tianocore/edk2/issues/48 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: Vladislav Vovchenko <vladislav.vovchenko@sk.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19791 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: execute option ROM images regardless of Secure BootLaszlo Ersek2016-01-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change the image verification policy for option ROM images to 0x00 (ALWAYS_EXECUTE). While this may not be a good idea for physical platforms (see e.g. <https://trmm.net/Thunderstrike>), on the QEMU platform the benefits seem to outweigh the drawbacks: - For QEMU's virtual PCI devices, and for some assigned PCI devices, the option ROMs come from host-side files, which can never be rewritten from within the guest. Since the host admin has full control over a guest anyway, executing option ROMs that originate from host-side files presents no additional threat to the guest. - For assigned physical PCI devices with option ROMs, the argument is not so clear-cut. In theory a setup could exist where: - the host-side UEFI firmware (with DENY_EXECUTE_ON_SECURITY_VIOLATION) rejects the option ROM of a malicious physical PCI device, but - when the device is assigned to the guest, OVMF executes the option ROM in the guest, - the option ROM breaks out of the guest (using an assumed QEMU vulnerability) and gains QEMU user privileges on the host. However, in order to escalate as far as it would happen on the bare metal with ALWAYS_EXECUTE (i.e., in order to gain firmware-level access on the host), the malicious option ROM would have to break through (1) QEMU, (2) traditional UID and GID based privilege separation on the host, (3) sVirt (SELinux) on the host, (4) the host OS - host firmware boundary. This is not impossible, but not likely enough to discourage the use cases below. - This patch makes it possible to use unsigned iPXE network drivers that QEMU presents in the option ROMs of virtual NICs and assigned SR-IOV VFs, even if Secure Boot is in User Mode or Deployed Mode. - The change also makes it possible to execute unsigned, outdated (revoked), or downright malicious option ROMs of assigned physical devices in guests, for corporate, entertainment, academia, or security research purposes. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Chao Zhang <chao.b.zhang@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: Chao Zhang <chao.b.zhang@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19614 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-04 10:17:19 +0000