summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/OvmfPkgIa32X64.dsc
Commit message (Collapse)AuthorAgeFilesLines
* 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/OvmfPkgIa32X64.dsc: Move PcdShellFile to [PcdsFixedAtBuild.X64]Ruiyu Ni2016-05-041-1/+1
| | | | | | | | PcdShellFile is never used in the PEI phase. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.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-1/+2
| | | | | | | | | | | | | 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: PlatformPei: determine the 64-bit PCI host aperture for X64 DXELaszlo Ersek2016-03-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main observation about the 64-bit PCI host aperture is that it is the highest part of the useful address space. It impacts the top of the GCD memory space map, and, consequently, our maximum address width calculation for the CPU HOB too. Thus, modify the GetFirstNonAddress() function to consider the following areas above the high RAM, while calculating the first non-address (i.e., the highest inclusive address, plus one): - the memory hotplug area (optional, the size comes from QEMU), - the 64-bit PCI host aperture (we set a default size). While computing the first non-address, capture the base and the size of the 64-bit PCI host aperture at once in PCDs, since they are natural parts of the calculation. (Similarly to how PcdPciMmio32* are not rewritten on the S3 resume path (see the InitializePlatform() -> MemMapInitialization() condition), nor are PcdPciMmio64*. Only the core PciHostBridgeDxe driver consumes them, through our PciHostBridgeLib instance.) Set 32GB as the default size for the aperture. Issue#59 mentions the NVIDIA Tesla K80 as an assignable device. According to nvidia.com, these cards may have 24GB of memory (probably 16GB + 8GB BARs). As a strictly experimental feature, the user can specify the size of the aperture (in MB) as well, with the QEMU option -fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536 The "X-" prefix follows the QEMU tradition (spelled "x-" there), meaning that the property is experimental, unstable, and might go away any time. Gerd has proposed heuristics for sizing the aperture automatically (based on 1GB page support and PCPU address width), but such should be delayed to a later patch (which may very well back out "X-PciMmio64Mb" then). For "everyday" guests, the 32GB default for the aperture size shouldn't impact the PEI memory demand (the size of the page tables that the DXE IPL PEIM builds). Namely, we've never reported narrower than 36-bit addresses; the DXE IPL PEIM has always built page tables for 64GB at least. For the aperture to bump the address width above 36 bits, either the guest must have quite a bit of memory itself (in which case the additional PEI memory demand shouldn't matter), or the user must specify a large aperture manually with "X-PciMmio64Mb" (and then he or she is also responsible for giving enough RAM to the VM, to satisfy the PEI memory demand). Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Thomas Lamprecht <t.lamprecht@proxmox.com> Ref: https://github.com/tianocore/edk2/issues/59 Ref: http://www.nvidia.com/object/tesla-servers.html Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: 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
* OvmfPkg: inherit Image Verification Policy defaults from SecurityPkgLaszlo Ersek2016-01-071-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Secure Boot support was originally addded to OvmfPkg on 2012-Mar-09, in SVN r13093 (git 8cee3de7e9f4), titled OvmfPkg: Enable secure-boot support when SECURE_BOOT_ENABLE==TRUE At that time the image verification policies in SecurityPkg/SecurityPkg.dec were: - option ROM image: 0x00 (ALWAYS_EXECUTE) - removable media image: 0x05 (QUERY_USER_ON_SECURITY_VIOLATION) - fixed media image: 0x05 (QUERY_USER_ON_SECURITY_VIOLATION) The author of SVN r13093 apparently didn't want to depend on the SecurityPkg defaults for the latter two image origins, plus the ALWAYS_EXECUTE policy for option ROM images must have been deemed too lax. For this reason SVN r13093 immediately spelled out 0x05 (QUERY_USER_ON_SECURITY_VIOLATION) within OvmfPkg for all three image origins. Fast forward to 2013-Aug-28: policy 0x05 (QUERY_USER_ON_SECURITY_VIOLATION) had been forbidden in the UEFI spec, and SVN r14607 (git db44ea6c4e09) reflected this in the source code: - The policies for the latter two image origins were switched from 0x05 to 0x04 (DENY_EXECUTE_ON_SECURITY_VIOLATION) in SecurityPkg, - the patch changed the default policy for option ROM images too, from 0x00 (ALWAYS_EXECUTE) to 0x04 (DENY_EXECUTE_ON_SECURITY_VIOLATION), - any other client DSC files, including OvmfPkg's, underwent a whole-sale 0x05 (QUERY_USER_ON_SECURITY_VIOLATION) -> 0x04 (DENY_EXECUTE_ON_SECURITY_VIOLATION) replacement too. The practical result of that patch for OvmfPkg was that the explicit 0x04 settings would equal the strict SecurityPkg defaults exactly. And that's what we have today: the "override the default values from SecurityPkg" comments in OvmfPkg's DSC files are stale, in practice. It is extremely unlikely that SecurityPkg would change the defaults from 0x04 (DENY_EXECUTE_ON_SECURITY_VIOLATION) any time in the future, so let's just inherit those in OvmfPkg. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Fu Siyuan <siyuan.fu@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: Fu Siyuan <siyuan.fu@intel.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@19613 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: pull in SMM-based variable driver stackLaszlo Ersek2015-11-301-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | When -D SMM_REQUIRE is given, replace both - OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf and - OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf with - OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf. The outermost (= runtime DXE driver) VariableSmmRuntimeDxe enters SMM, and the rest: - the privileged half of the variable driver, VariableSmm, - the fault tolerant write driver, FaultTolerantWriteSmm, - and the FVB driver, FvbServicesSmm, work in SMM purely. We also resolve the BaseCryptLib class for DXE_SMM_DRIVER modules, for the authenticated VariableSmm driver's sake. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19065 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: consolidate variable driver stack in DSC and FDF filesLaszlo Ersek2015-11-301-10/+14
| | | | | | | | | | | | | | | | | | | | | | | | The following modules constitute the variable driver stack: - QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, runtime alternatives for providing the Firmware Volume Block(2) Protocol, dependent on qemu pflash presence, - FaultTolerantWriteDxe, providing the Fault Tolerant Write Protocol, - MdeModulePkg/Universal/Variable/RuntimeDxe, independently of -D SECURE_BOOT_ENABLE, providing the Variable and Variable Write Architectural Protocols. Let's move these drivers closer to each other in the DSC and FDF files, so that we can switch the variable driver stack to SMM with more local changes. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19064 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: build PiSmmCpuDxeSmm for -D SMM_REQUIRELaszlo Ersek2015-11-301-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | At this point we can enable building PiSmmCpuDxeSmm. CPU specific features, like SMRR detection, and functions that are used to initialize SMM and process SMIs, are abstracted through the SmmCpuFeaturesLib class for the PiSmmCpuDxeSmm module. Resolve it to our own implementation under OvmfPkg -- it allows PiSmmCpuDxeSmm to work with QEMU's and KVM's 64-bit state save map format, which follows the definition from AMD's programmer manual. SmmCpuPlatformHookLib provides platform specific functions that are used to initialize SMM and process SMIs. Resolve it to the one Null instance provided by UefiCpuPkg, which is expected to work for most platforms. Cc: Paolo Bonzini <pbonzini@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> [pbonzini@redhat.com: resolve the SmmCpuFeaturesLib class to OVMF's own instance] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19061 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: build CpuS3DataDxe for -D SMM_REQUIRELaszlo Ersek2015-11-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PiSmmCpuDxeSmm driver from UefiCpuPkg depends on the ACPI_CPU_DATA structure -- created by a platform- and CPU-specific driver -- in order to support ACPI S3. The address of this structure is communicated through the dynamic PCD PcdCpuS3DataAddress. The "UefiCpuPkg/Include/AcpiCpuData.h" header file documents the fields of this structure in detail. The simple/generic "UefiCpuPkg/CpuS3DataDxe" driver creates and populates the structure in a conformant way, and it co-operates well with PiSmmCpuDxeSmm, for OVMF's purposes. PlatformBdsLib CpuS3DataDxe PiSmmCpuDxeSmm S3Resume2Pei (DXE_DRIVER) (DXE_DRIVER) (DXE_SMM_DRIVER) (PEIM) -------------- --------------- ---------------- -------------- normal collects data boot except MTRR settings into ACPI_CPU_DATA sets PcdCpuS3Da... signals End-of-Dxe | +----------> collects MTRR settings into ACPI_CPU_DATA installs [Dxe]Smm ReadyToLock | +---------------------------> fetches PcdCpuS3Dat... copies ACPI_CPU_DATA into SMRAM runtime S3 suspend S3 transfers resume control to PiSmmCpuDxe... | uses <----+ ACPI_CPU_DATA from SMRAM 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: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19060 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-29 00:11:42 +0000