summaryrefslogtreecommitdiff
path: root/OvmfPkg
AgeCommit message (Collapse)Author
2016-03-10OvmfPkg: PciHostBridgeLib: permit access to the full extended config spaceLaszlo Ersek
By now OVMF makes MdeModulePkg/Bus/Pci/PciHostBridgeDxe go through MMCONFIG (when running on Q35). Enable the driver to address each B/D/F's config space up to and including offset 0xFFF. 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>
2016-03-10OvmfPkg: match PCI config access to machine type (if not USE_OLD_PCI_HOST)Laszlo Ersek
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>
2016-03-10OvmfPkg: add DxePciLibI440FxQ35Laszlo Ersek
This library is a trivial unification of the following two PciLib instances (and the result is easily diffable against each): - MdePkg/Library/BasePciLibCf8 - MdePkg/Library/BasePciLibPciExpress The PCI config access method is determined in the constructor function, from the dynamic PCD "PcdOvmfHostBridgePciDevId" that is set by PlatformPei. The library instance is usable in DXE phase or later modules: the PciLib instances being unified have no firmware phase / client module type restrictions, and here the only PCD access is made in the constructor function. That is, even before a given client executable's entry point is invoked. The library instance depends on PlatformPei both for setting the PCD mentioned above, and also for enabling MMCONFIG on Q35. PEI and earlier phase modules are not expected to need extended config access even 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> 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>
2016-03-10OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35Laszlo Ersek
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>
2016-03-10OvmfPkg: PlatformPei: lower the 32-bit PCI MMIO base to 2GB on Q35Laszlo Ersek
Gerd has advised us that long term support Q35 machine types have no low RAM above 2GB, hence we should utilize the [2GB, 3GB) gap -- that we currently leave unused -- for MMIO. (Plus, later in this series, for the PCIEXBAR too.) 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.edk2.devel/8707/focus=8817 Suggested-by: Gerd Hoffmann <kraxel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@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>
2016-03-10OvmfPkg: IndustryStandard/Q35MchIch9.h: add PCIEXBAR macrosLaszlo Ersek
Section 5.1.16 ("PCIEXBAR -- PCI Express Register Range Base Address") in Intel document #316966-002 (already referenced near the top of this header file) describes the Q35 DRAM Controller register that configures the memory-mapped PCI config space (also known as MMCONFIG, and ECAM / Enhanced Configuration Access Method). In this patch we add the macros we'll need later. We'll only support the 256 MB memory-mapped config space -- enough for buses [0, 255]. 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 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@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>
2016-03-08OvmfPkg: Enable Network2 Shell Commands for IPv6Gary Lin
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>
2016-03-08OvmfPkg PciHostBridgeDxe: Convert X64/IoFifo.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert X64/IoFifo.asm to X64/IoFifo.nasm 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>
2016-03-08OvmfPkg PciHostBridgeDxe: Convert Ia32/IoFifo.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert Ia32/IoFifo.asm to Ia32/IoFifo.nasm 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>
2016-03-03OvmfPkg: switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxeLaszlo Ersek
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>
2016-03-03OvmfPkg: resolve PciSegmentLibLaszlo Ersek
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>
2016-03-03OvmfPkg: PciHostBridgeLib: initialize RootBus->DevicePathLaszlo Ersek
We copy the code from InitRootBridge() [OvmfPkg/PciHostBridgeDxe/PciHostBridge.c], with a slight change: the device path is allocated separately now. This is the final field to initialize in PCI_ROOT_BRIDGE. The type EFI_PCI_ROOT_BRIDGE_DEVICE_PATH is renamed to OVMF_PCI_ROOT_BRIDGE_DEVICE_PATH. The original is a misnomer (it is not a standard UEFI type) that dates back to PcAtChipsetPkg/PciHostBridgeDxe. Simply removing the EFI_ suffix would result in PCI_ROOT_BRIDGE_DEVICE_PATH, where PCI_ could incorrectly suggest a relation with the PCI standards or the PCI-related generic edk2 code. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03OvmfPkg: PciHostBridgeLib: set RootBus->NoExtendedConfigSpaceLaszlo Ersek
In "OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c", the RootBridgeIoCheckParameter() function hard-codes the maximum offset for the PCI config space as 0xFF (see the MAX_PCI_REG_ADDRESS macro), which matches OVMF's 0xCF8 / 0xCFC config access method. The "MdeModulePkg/Bus/Pci/PciHostBridgeDxe" driver abstracts away config space access via the PciSegmentLib class, so it has to be informed separately about the config space size. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03OvmfPkg: PciHostBridgeLib: set bus, IO and 32-bit MMIO windows in RootBusLaszlo Ersek
The bus aperture is copied verbatim from InitRootBridge() [OvmfPkg/PciHostBridgeDxe/PciHostBridge.c]. The IO and 32-bit MMIO apertures are matched to PlatformPei's settings. PciHostBridgeLibDxe expects PciHostBridgeLib instances to advertize the exact apertures. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03OvmfPkg: PciHostBridgeLib: set RootBus->AllocationAttributesLaszlo Ersek
InitRootBridge() in "OvmfPkg/PciHostBridgeDxe/PciHostBridge.c" passes the EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM allocation attribute to RootBridgeConstructor(); we should do the same here. From "MdePkg/Include/Protocol/PciHostBridgeResourceAllocation.h": /// If this bit is set, then the PCI Root Bridge does not support separate /// windows for Non-prefetchable and Prefetchable memory. A PCI bus driver /// needs to include requests for Prefetchable memory in the /// Non-prefetchable memory pool. Which implies that both the 32-bit and 64-bit prefetchable MMIO apertures should be marked empty. (The CreateRootBridge() function actually enforces this in "MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c".) Furthermore, since OvmfPkg/PciHostBridgeDxe does *not* set the EFI_PCI_HOST_BRIDGE_MEM64_DECODE allocation attribute: /// If this bit is set, then the PCI Root Bridge supports 64 bit memory /// windows. If this bit is not set, the PCI bus driver needs to include /// requests for 64 bit memory address in the corresponding 32 bit memory /// pool. we follow suit in the PciHostBridgeLib instance. In turn, the 64-bit MMIO apertures (both prefetchable and non-prefetchable) should be marked empty. MdeModulePkg/Bus/Pci/PciHostBridgeDxe enforces this too. (64-bit MMIO aperture support, based on yet more fw_cfg files, is a planned future improvement.) Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03OvmfPkg: PciHostBridgeLib: clear RootBus->DmaAbove4GLaszlo Ersek
When this BOOLEAN member is FALSE, and the caller tries to set up a DMA transfer between a PCI device and a host buffer not entirely under 4GB, then "MdeModulePkg/Bus/Pci/PciHostBridgeDxe" sets up a bounce buffer under 4GB, in the implementation of EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Map(). Since that's exactly what RootBridgeIoMap() does in "OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c", stick with it in this conversion. 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>
2016-03-03OvmfPkg: PciHostBridgeLib: set supported and initial attributes in RootBusLaszlo Ersek
These settings are copied from the RootBridgeConstructor() function, file "OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c". Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03OvmfPkg: PciHostBridgeLib: set RootBus->SegmentLaszlo Ersek
This is the first of the patches that set the fields of PCI_ROOT_BRIDGE. The structure is zero-filled as a precaution for later field additions. Here we set the Segment member explicitly to zero (so that any later customization can be easier). Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03OvmfPkg: PciHostBridgeLib: implement PciHostBridgeFreeRootBridges()Laszlo Ersek
This function has no counterpart in OvmfPkg/PciHostBridgeDxe/, but the PciHostBridgeLib class requires it. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03OvmfPkg: PciHostBridgeLib: convert main loop from PciHostBridgeDxeLaszlo Ersek
In this patch we import the scan for extra root buses from the InitializePciHostBridge() function, in file "OvmfPkg/PciHostBridgeDxe/PciHostBridge.c". For the time being, the InitRootBridge() and UninitRootBridge() functions are just placeholders. The PciHostBridgeGetRootBridges() API expects us to return the PCI_ROOT_BRIDGE structures in a contiguous array, instead of a linked list. Therefore the following bits have to be converted manually: (1) The array is allocated in advance, in a single step. (2) The calculation of the array size depends on an explicit multiplication, which we must check against overflow. Since more than 255 extra root bridges make no sense anyway, we use (1 + 255) as the limit on the main plus all extra root bridges. This also ensures that the UINTN multiplication doesn't overflow. (3) The PciHostBridgeDxe code decrements "ExtraRootBridgesLeft" to terminate the scanning early. Here we need track the increasing count of used array elements as well, so we employ "ExtraRootBridges" as a constant limit, and increment the new local variable "Initialized". (4) The prototypes of InitRootBridge() and UninitRootBridge() reflect that the PCI_ROOT_BRIDGE structure is allocated by the caller; only in-place initialization is necessary. Additionally, macros are employed for standard PCI quantities, from "MdePkg/Include/IndustryStandard/Pci22.h": - MAX_PCI_DEVICE_NUMBER (31) is replaced with PCI_MAX_DEVICE (same), - the constant 255 is replaced with PCI_MAX_BUS, - the (RootBridgeNumber < 256) condition is replaced with (RootBridgeNumber <= PCI_MAX_BUS). Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03OvmfPkg: clone PciHostBridgeLib from MdeModulePkg's Null instanceLaszlo Ersek
In this patch we clone "MdeModulePkg/Library/PciHostBridgeLibNull" for customization under OvmfPkg. Differences relative to a verbatim copy: - the Null suffix is dropped from file names, - the UNI file is dropped, together with the corresponding MODULE_UNI_FILE reference in the INF file, - the INF file receives a new FILE_GUID, - the top comments in the files mention OVMF, not a null instance. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03OvmfPkg: factor the MMIO aperture shared by all PCI root bridges into PCDsLaszlo Ersek
Going forward, two modules will need to know about the aperture: PlatformPei (as before), and OVMF's upcoming PciHostBridgeLib instance (because the core PciHostBridgeDxe driver requires the library to state the exact apertures for all root bridges). On QEMU, all root bridges share the same MMIO aperture, hence one pair of PCDs suffices. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03OvmfPkg: factor the IO aperture shared by all PCI root bridges into PCDsLaszlo Ersek
At the moment we don't intend to customize this aperture at runtime, but going forward, two modules will need to know about it: PlatformPei (as before), and OVMF's upcoming PciHostBridgeLib instance (because the core PciHostBridgeDxe driver requires the library to state the exact apertures for all root bridges). On QEMU, all root bridges share the same IO port aperture, hence one pair of PCDs suffices. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03OvmfPkg: remove superfluous [PcdsFixedAtBuild] section headerLaszlo Ersek
At the location of this header an earlier [PcdsFixedAtBuild] section is in effect already. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-02OvmfPkg: copy log level comments from DebugLib.hLaszlo Ersek
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>
2016-02-26OvmfPkg: Add FileExplorerLib.inf to the dsc fileDandan Bi
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>
2016-02-24OvmfPkg: add driver for Virtio-RNG deviceArd Biesheuvel
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>
2016-02-24OvmfPkg: implement UEFI driver for Virtio RNG devicesArd Biesheuvel
This implements a UEFI driver model driver for Virtio devices of type VIRTIO_SUBSYSTEM_ENTROPY_SOURCE, and exposes them via instances of the EFI_RNG_PROTOCOL protocol, supporting the EFI_RNG_ALGORITHM_RAW algorithm only. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2016-02-24OvmfPkg: VirtioFlush(): return the number of bytes written by the hostLaszlo Ersek
VirtioLib provides an API for simple, synchronous (request/response-style) virtio communication. The guest driver builds one descriptor chain, link for link, with VirtioPrepare() and VirtioAppendDesc(), then submits the chain, and awaits the processing, with VirtioFlush(). The descriptor chain is always built at the beginning of the descriptor area, with the head descriptor having descriptor index 0. In order to submit the descriptor chain to the host, the guest always pushes a new "available element" to the Available Ring, in genuine queue-like fashion, with the new element referencing the head descriptor (which always has index 0, see above). In turn, after processing, the host always pushes a new "used element" to the Used Ring, in genuine queue-like fashion, with the new element referencing the head descriptor of the chain that was just processed. The same element also reports the number of bytes that the host wrote, consecutively across the host-writeable buffers that were linked by the descriptors. (See "OvmfPkg/VirtioNetDxe/TechNotes.txt" for a diagram about the descriptor area and the rings.) Because at most one descriptor chain can be in flight with VirtioLib at any time, - the Available Ring and the Used Ring proceed in lock-step, - and the head descriptor that the new "available" and "used" elements can ever reference has index 0. Based on the above, we can modify VirtioFlush() to return the number of bytes written by the host across the descriptor chain. The virtio-block and virtio-scsi drivers don't care (they have other ways to parse the data produced by the host), while the virtio-net driver doesn't use VirtioFlush() at all (it employs VirtioLib only to set up its rings). However, the virtio entropy device, to be covered in the upcoming patches, reports the amount of randomness produced by the host only through this quantity. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-02-15OvmfPkg: simplify VARIABLE_STORE_HEADER generationLaszlo Ersek
Before the merger of the authenticated and non-authenticated variable drivers (commit fa0737a839d0), we had to match the varstore header GUID in "OvmfPkg/VarStore.fdf.inc" to SECURE_BOOT_ENABLE, because the opposite GUID would cause either driver to fail an assertion. The header structures for individual variables residing in the varstore were different (VARIABLE_HEADER vs. AUTHENTICATED_VARIABLE_HEADER), and each driver could only handle its own, so this GUID enforcement was necessary. Since the unification of the variable driver however, it treats (a) variable store format, and (b) AuthVariableLib instance as independent characteristics; it can always manipulate variable stores with both header types. All variations boot now; the difference is whether authenticated variables, and special variables computed from them (like SecureBoot) are supported at runtime: variable store non-auth auth and SB header GUID AuthVariableLib variables variables -- --------------------- ------------------- -> --------- ----------- 1 Variable SecurityPkg/... supported unsupported 2 Variable AuthVariableLibNull supported unsupported 3 AuthenticatedVariable SecurityPkg/... supported supported 4 AuthenticatedVariable AuthVariableLibNull supported unsupported At the moment, SECURE_BOOT_ENABLE selects between cases #2 (FALSE) and #3 (TRUE). That is, it controls both the varstore header GUID in "OvmfPkg/VarStore.fdf.inc", and the AuthVariableLib resolution in the DSC files. Exploiting the unified driver's flexibility, we can simplify "OvmfPkg/VarStore.fdf.inc" by picking the AuthenticatedVariable GUID as a constant, and letting SECURE_BOOT_ENABLE control only the AuthVariableLib resolution. This amounts to SECURE_BOOT_ENABLE choosing between cases #3 (TRUE) and #4 (FALSE), with identical results as before. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Star Zeng <star.zeng@intel.com> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/7319/focus=7344 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: Star Zeng <star.zeng@intel.com>
2016-02-02OvmfPkg: QemuBootOrderLib: recognize NVMe devicesLaszlo Ersek
This patch enables QemuBootOrderLib to parse OFW device paths formatted by QEMU commit a907ec52cc1a: nvme: generate OpenFirmware device path in the "bootorder" fw_cfg file With both patches applied, OVMF will honor the bootindex=N property of the NVMe device: -drive id=drive0,if=none,format=FORMAT,file=PATHNAME \ -device nvme,drive=drive0,serial=SERIAL,bootindex=N ^^^^^^^^^^^ 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@19792 6f19259b-4bc3-4df7-8a09-765794883524
2016-02-02OvmfPkg: include NvmExpressDxe driverLaszlo Ersek
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
2016-01-29OvmfPkg: Increase default RELEASE build image size to 2MBJordan Justen
Fixes: https://github.com/tianocore/edk2/issues/47 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Bruce Cran <bruce@cran.org.uk> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19775 6f19259b-4bc3-4df7-8a09-765794883524
2016-01-07OvmfPkg: execute option ROM images regardless of Secure BootLaszlo Ersek
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
2016-01-07OvmfPkg: inherit Image Verification Policy defaults from SecurityPkgLaszlo Ersek
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
2015-12-17OvfmPkg/XenHypercallLib: add missing GCC_ASM_EXPORT to XenHypercall2Ard Biesheuvel
GCC_ASM_EXPORT() not only exports a symbol as a function, it also emits a .type <xxx>, %function directive, which is used by the ARM linker to decide whether to emit interworking branches. So replace the explicit .global with GCC_ASM_EXPORT(), or the code will not be callable from Thumb-2 code. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19329 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-04OvmfPkg: Fix VS2015 warning C4459 in XenBusDxeLiming Gao
warning C4459: declaration of 'xs' hides global declaration. Update code to rename local variable xs to xsp to be different. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19116 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: replace README fine print about X64 SMM S3 with PlatformPei checkLaszlo Ersek
At the moment, the "UefiCpuPkg/Universal/Acpi/S3Resume2Pei" module doesn't support S3 resume if the platform has SMM enabled and the PEI phase is built for X64. We document this in the README, but it is not conspicuous enough. Replace the "fine print" in the README with a runtime check in PlatformPei. Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19070 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: README: document SMM statusLaszlo Ersek
Cc: Paolo Bonzini <pbonzini@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> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19066 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: pull in SMM-based variable driver stackLaszlo Ersek
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
2015-11-30OvmfPkg: consolidate variable driver stack in DSC and FDF filesLaszlo Ersek
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
2015-11-30OvmfPkg: QemuFlashFvbServicesRuntimeDxe: adhere to -D SMM_REQUIRELaszlo Ersek
When the user requires "security" by passing -D SMM_REQUIRE, and consequently by setting PcdSmmSmramRequire, enforce flash-based variables. Furthermore, add two ASSERT()s to catch if the wrong module were pulled into the build. 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@19063 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: QemuFlashFvbServicesRuntimeDxe: add DXE_SMM_DRIVER buildLaszlo Ersek
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@19062 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: build PiSmmCpuDxeSmm for -D SMM_REQUIRELaszlo Ersek
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
2015-11-30OvmfPkg: build CpuS3DataDxe for -D SMM_REQUIRELaszlo Ersek
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
2015-11-30OvmfPkg: any AP in SMM should not wait for the BSP for more than 100 msLaszlo Ersek
This patch complements the previous one, "OvmfPkg: use relaxed AP SMM synchronization mode". While that patch focuses on the case when the SMI is raised synchronously by the BSP, on the BSP: BSPHandler() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c] SmmWaitForApArrival() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c] IsSyncTimerTimeout() [UefiCpuPkg/PiSmmCpuDxeSmm/SyncTimer.c] this patch concerns itself with the case when it is one of the APs that raises (and sees delivered) the synchronous SMI: APHandler() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c] IsSyncTimerTimeout() [UefiCpuPkg/PiSmmCpuDxeSmm/SyncTimer.c] Namely, in APHandler() the AP waits for the BSP to enter SMM regardless of PcdCpuSmmSyncMode, for PcdCpuSmmApSyncTimeout microseconds (the default value is 1 second). If the BSP doesn't show up in SMM within that interval, then the AP brings it in with a directed SMI, and waits for the BSP again for PcdCpuSmmApSyncTimeout microseconds. Although during boot services, SmmControl2DxeTrigger() is only called by the BSP, at runtime the OS can invoke runtime services from an AP (it can even be forced with "taskset -c 1 efibootmgr"). Because on QEMU SmmControl2DxeTrigger() only raises the SMI for the calling processor (BSP and AP alike), the first interval above times out invariably in such cases -- the BSP never shows up before the AP calls it in. In order to mitigate the performance penalty, decrease PcdCpuSmmApSyncTimeout to one tenth of its default value: 100 ms. (For comparison, Vlv2TbltDevicePkg sets 1 ms.) NOTE: once QEMU becomes capable of synchronous broadcast SMIs, this patch and the previous one ("OvmfPkg: use relaxed AP SMM synchronization mode") should be reverted, and SmmControl2DxeTrigger() should be adjusted instead. Cc: Paolo Bonzini <pbonzini@redhat.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: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19059 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: use relaxed AP SMM synchronization modePaolo Bonzini
Port 0xb2 on QEMU only sends an SMI to the currently executing processor. The SMI handler, however, and in particular SmmWaitForApArrival, currently expects that SmmControl2DxeTrigger triggers an SMI IPI on all processors rather than just the BSP. Thus all SMM invocations loop for a second (the default value of PcdCpuSmmApSyncTimeout) before SmmWaitForApArrival sends another SMI IPI to the APs. With the default SmmCpuFeaturesLib, 32-bit machines must broadcast SMIs because 32-bit machines must reset the MTRRs on each entry to system management modes (they have no SMRRs). However, our virtual platform does not have problems with cacheability of SMRAM, so we can use "directed" SMIs instead. To do this, just set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode to 1 (aka SmmCpuSyncModeRelaxedAp). This fixes SMM on multiprocessor virtual machines. 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@19058 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: SmmCpuFeaturesLib: customize state save map formatPaolo Bonzini
This adjusts the previously introduced state save map access functions, to account for QEMU and KVM's 64-bit state save map following the AMD spec rather than the Intel one. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [lersek@redhat.com: reflow commit message, convert patch to CRLF] Cc: Paolo Bonzini <pbonzini@redhat.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@19057 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: SmmCpuFeaturesLib: implement SMRAM state save map accessPaolo Bonzini
This implementation copies SMRAM state save map access from the PiSmmCpuDxeSmm module. The most notable change is: - dropping support for EFI_SMM_SAVE_STATE_REGISTER_IO - changing the implementation of EFI_SMM_SAVE_STATE_REGISTER_LMA to use the SMM revision id instead of a local variable (which UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c initializes from CPUID's LM bit). This accounts for QEMU's implementation of x86_64, which always uses revision 0x20064 even if the LM bit is zero. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [lersek@redhat.com: reflow commit message & fix typo, convert patch to CRLF] Cc: Paolo Bonzini <pbonzini@redhat.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@19056 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30OvmfPkg: SmmCpuFeaturesLib: remove unnecessary bitsPaolo Bonzini
SMRR, MTRR, and SMM Feature Control support is not needed on a virtual platform. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: insert space between ASSERT and (), convert to CRLF, refresh against SVN r18958] Cc: Paolo Bonzini <pbonzini@redhat.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@19055 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-07 15:47:50 +0000