summaryrefslogtreecommitdiff
path: root/OvmfPkg/Library
AgeCommit message (Collapse)Author
2015-05-13OvmfPkg: extract some bits and port offsets common to Q35 and I440FXLaszlo Ersek
The PMBA_RTE and ACPI_TIMER_OFFSET macros apply equally to both boards, plus they are triplicated between the various AcpiTimerLib instances. Define them centrally in "OvmfPlatforms.h". Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17436 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: consolidate POWER_MGMT_REGISTER_PIIX4() on "I440FxPiix4.h" macrosLaszlo Ersek
All POWER_MGMT_REGISTER_PIIX4() macro invocations in OvmfPkg should use the macros in "I440FxPiix4.h" as arguments. Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17435 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: consolidate POWER_MGMT_REGISTER_Q35() on "Q35MchIch9.h" macrosLaszlo Ersek
All POWER_MGMT_REGISTER_Q35() macro invocations in OvmfPkg should use the macros in "Q35MchIch9.h" as arguments. Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17434 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-08OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridgesLaszlo Ersek
When the Q35 machine type(s) of QEMU are used with libvirt, libvirt tends to place some devices behind PCI bridges. This is then reflected in the "bootorder" fw_cfg file. For example: /pci@i0cf8/pci-bridge@1e/pci-bridge@1/scsi@5/disk@0,0 /pci@i0cf8/pci-bridge@1e/pci-bridge@1/scsi@3/channel@0/disk@0,0 As yet QemuBootOrderLib doesn't support such OFW device paths. Add code that translates a sequence of pci-bridge nodes. In practice libvirt seems to insert two such nodes (*), hence increment EXAMINED_OFW_NODES with the same number. (* Background, paraphrasing Laine Stump's words: When the machine type is Q35, we create a dmi-to-pci bridge coming off of the pcie root controller, and a pci-to-pci bridge coming off of that, then attach most devices to the pci-to-pci bridge. This is done because you can't hotplug into pcie-root, can't (or at least shouldn't) plug a pci-to-pci bridge into pcie-root (so the next one has to be dmi-to-pci-bridge), and can't hotplug into dmi-to-pci-bridge (so you need to have a pci-to-pci bridge).) 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@17385 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-06OvmfPkg: Use the new PCDs defined in MdePkg and MdeModulePkg.Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17318 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-27OvmfPkg: XenConsoleSerialPortLib: deal with output overflowArd Biesheuvel
It is the responsibility of the SerialPortLib implementation to deal with flow control if the underlying medium cannot keep up with the inflow of data. So in our SerialPortWrite () function, we should spin as long as we need to in order to deliver all the data instead of giving up and returning a smaller value than the number of bytes we were given. Also, remove the 'if (Sent > 0)' condition on the signalling of the event channel: if the buffer is full and we haven't been able to add any more data, it makes perfect sense to signal the event channel again, even if we have done so before when we did write the data. Also, this patch brings the implementation of XenSerialPortLib in sync with the library class documentation. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: replace DebugLib dependency with open-coded ASSERT()] git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17079 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-26OvmfPkg: Q35: Use correct ACPI PM control register:bitGabriel Somlo
On PIIX4, function 3, the PMREGMISC register at offset 0x80, with default value 0x00 has its bit 0 (PMIOSE) indicate whether the PM IO space given in the PMBA register (offset 0x40) is enabled. PMBA must be configured *before* setting this bit. On Q35/ICH9+, function 0x1f, the equivalent role is fulfilled by bit 7 (ACPI_EN) in the ACPI Control Register (ACPI_CNTL) at offset 0x44, also with a default value of 0x00. Currently, OVMF hangs when Q35 reboots, because while PMBA is reset by QEMU, the register at offset 0x80 (matching PMREGMISC on PIIX4) is not reset, since it has a completely different meaning on LPC. As such, the power management initialization logic in OVMF finds the "PMIOSE" bit enabled after a reboot and decides to skip setting PMBA. This causes the ACPI timer tick routine to read a constant value from the wrong register, which in turn causes the ACPI delay loop to hang indefinitely. This patch modifies the Base[Rom]AcpiTimerLib constructors and the PlatformPei ACPI PM init routines to use ACPI_CNTL:ACPI_EN instead of PMREGMISC:PMIOSE when running on Q35. Reported-by: Reza Jelveh <reza.jelveh@tuhh.de> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17076 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-03OvmfPkg: replace strict XenHypercallLib construction with explicit queryLaszlo Ersek
XenHypercallLib has two clients at the moment: XenBusDxe and XenConsoleSerialPortLib. Currently, when XenBusDxe starts on a non-Xen X86 platform (ie. as part of OVMF not running on Xen), the X86XenHypercallLib instance built into it fails to initialize, which triggers an ASSERT() in auto-generated code. Instead, let's call XenHypercallIsAvailable() in the driver's entry point, and exit cleanly when the driver is started on a non-Xen platform. Modify the constructor of XenConsoleSerialPortLib similarly; we shouldn't proceed if Xen is not available. In practice this check should never fail, because XenConsoleSerialPortLib is only used on ARM, and ArmXenHypercallLib is always available; but nonetheless we should be pedantic. Reported-by: Gabriel L. Somlo <gsomlo@gmail.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> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17001 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-03OvmfPkg: XenHypercallLib: introduce XenHypercallIsAvailable()Laszlo Ersek
Similarly to QemuFwCfgLib, we prefer mellow library construction code and an explicit "are you available" query function in the XenHypercallLib class. In this step we introduce that query function, but move no client code to it yet. 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> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17000 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-03OvmfPkg: XenHypercallLib: add empty constructor for ARM & AARCH64Laszlo Ersek
In the next patch we'll add a simple query function to the XenHypercallLib library class that is supposed to be called by initialization code in modules. Among those, in constructors of dependent libraries too. Library construction ordering is ensured only between libraries with constructors, plus we shouldn't allow a dependent library with a constructor to call into any XenHypercallLib instances (the simple query function) before XenHypercallLib is constructed itself. For this reason, introduce an (empty) constructor for ARM & AARCH64 too. 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: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16999 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-03OvmfPkg, ArmVirtualizationPkg: clean up XenHypercallLib namesLaszlo Ersek
Perform the following renames in order to stick with edk2 tradition more closely: XenHypercallLibArm, XenHypercallLibIntel -> XenHypercallLib XenHypercallIntel -> X86XenHypercall In addition, we unify the INF files. This patch modifies ArmVirtualizationPkg and OvmfPkg at once, in order to keep both bisectable (client code shouldn't break). 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> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16998 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28ArmVirtualizationPkg: add XenIoMmioLibArd Biesheuvel
This adds a XenIoMmioLib declaration and implementation that can be invoked to install the XENIO_PROTOCOL and a corresponding grant table address on a EFI handle. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16979 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: add Xen PV console SerialPortLib driverArd Biesheuvel
This implements a SerialPortLib instance that wires up to the PV console ring used by domU guests. Also imports the required upstream Xen io/console.h header. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16976 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: implement XenHypercallLib for ARMArd Biesheuvel
This patch adds an implementation of XenHypercallLib for both AArch64 and AArch32 execution modes on ARM systems. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16974 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: move XenBusDxe hypercall code to separate libraryArd Biesheuvel
This moves all of the Xen hypercall code that was private to XenBusDxe to a new library class XenHypercallLib. This will allow us to reimplement it for ARM, and to export the Xen hypercall functionality to other parts of the code, such as a Xen console SerialPortLib driver. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16970 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-17OvmfPkg/PlatformBdsLib: Signal ReadyToBoot before booting QEMU kernelJordan Justen
Before we launch the QEMU kernel, we should signal the ReadyToBoot event. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16878 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-06OvmfPkg: Update PlatformBaseDebugLibIoPort libraryLiming Gao
Implement new API DebugPrintLevelEnabled() to base on PCD PcdFixedDebugPrintErrorLevel. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16797 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-14OvmfPkg: PlatformBdsLib: get front page timeout from QEMULaszlo Ersek
Put QemuBootOrderLib's GetFrontPageTimeoutFromQemu() to use, so that OVMF's Platform BDS policy can consume QEMU's command line option -boot menu=on,splash-time=N RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1170507 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@16611 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-14OvmfPkg: QemuBootOrderLib: expose QEMU's "-boot menu=on[,splash-time=N]"Laszlo Ersek
The QEMU command line option -boot menu=on is meant to have the guest firmware wait for a firmware-specific interval for the user to enter the boot menu. During the wait, the user can opt to enter the boot menu, or interrupt the wait and proceed to booting at once. If the wait interval elapses, the firmware should boot as it normally would. The QEMU command line option -boot menu=on,splash-time=N means the same, except the firmware should wait for cca. N milliseconds instead of a firmware-specific interval. We can approximate this behavior quite well for edk2's virtual platforms because the Intel BDS front page already supports a progress bar, with semantics similar to the above. Let's distill the fw_cfg bits underlying "-boot menu=on,splash-time=N" for the BDS policies, in the form of a timeout value they can pass to Intel's PlatformBdsEnterFrontPage(). If the boot menu is not requested, we return "gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut", which is what the virtual platforms use right now. If the boot menu is requested without specifying the timeout, we return the same PCD, unless it would cause us to skip the boot menu at once. In the latter case, we return 3 seconds (as an approximation of the 2500 ms SeaBIOS default.) RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1170507 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: Olivier Martin <Olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16610 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02OvmfPkg: QemuBootOrderLib: OFW-to-UEFI translation for virtio-mmioLaszlo Ersek
The TranslateMmioOfwNodes() function recognizes the following OpenFirmware device paths: virtio-blk: /virtio-mmio@000000000a003c00/disk@0,0 virtio-scsi disk: /virtio-mmio@000000000a003a00/channel@0/disk@2,3 virtio-net NIC: /virtio-mmio@000000000a003e00/ethernet-phy@0 The new translation can be enabled with the "PcdQemuBootOrderMmioTranslation" Feature PCD. This PCD also controls if the "survival policy" covers unselected boot options that start with the virtio-mmio VenHw() node. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16575 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02OvmfPkg: QemuBootOrderLib: widen ParseUnitAddressHexList() to UINT64Laszlo Ersek
The OpenFirmware device path nodes that QEMU generates for virtio-mmio transports contain 64-bit hexadecimal values (16 nibbles) -- the base addresses of the register blocks. In order to parse them soon, ParseUnitAddressHexList() must parse UINT64 values. Call sites need to be adapted, as expected. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16574 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02OvmfPkg: QemuBootOrderLib: featurize PCI-like device path translationLaszlo Ersek
In preparation for adding OpenFirmware-to-UEFI translation for "MMIO-like" OFW device path fragments, let's turn the currently exclusive "PCI-like" translation into "just one" of the possible translations. - Rename TranslateOfwNodes() to TranslatePciOfwNodes(), because it is tightly coupled to "PCI-like" translations. - Rename REQUIRED_OFW_NODES to REQUIRED_PCI_OFW_NODES, because this macro is specific to TranslatePciOfwNodes(). - Introduce a new wrapper function under the original TranslateOfwNodes() name. This function is supposed to try translations in some order until a specific translation returns a status different from RETURN_UNSUPPORTED. - Introduce a new Feature PCD that controls whether PCI translation is attempted at all. - The boot option "survival policy" in BootOrderComplete() must take into account if the user was able to select PCI-like boot options. If the user had no such possibility (because the Feature PCD was off for PCI-like translation), then we ought to keep any such unselected boot options. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16571 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02OvmfPkg: extract QemuBootOrderLibLaszlo Ersek
and rebase OvmfPkg's PlatformBdsLib on the standalone library. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16570 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-17OvmfPkg: PlatformBdsLib: Dynamic PCI Interrupt Line register setupGabriel Somlo
Remove hard-coded list of PCI devices for which the Interrupt Line register is initialized. Instead, provide a "visitor" function to initialize the register only for present and applicable PCI devices. At this time, we match the behavior of SeaBIOS (file src/fw/pciinit.c, functions *_pci_slot_get_irq() and "map the interrupt" block from pci_bios_init_device()). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Gerd Hoffmann <kraxel@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@16398 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: PlatformBdsLib: Platform dependent PCI/IRQ initializationGabriel Somlo
Merge PciInitialization() and AcpiInitialization() into a single function, PciAcpiInitialization(), and use a PCD set during PEI to detect the underlying platform type (PIIX4 or Q35/MCH) and therefore the addresses of the registers to be initialized. Add LNK[A-H] routing target initialization for the Q35 platform. Additionally, initialize PCI_INTERRUPT_LINE registers for the typical set of PCI devices included by QEMU with the Q35 machine type. The corresponding PIIX4 initialization of PCI_INTERRUPT_LINE registers is cleaned up and the list of PIIX4 PCI devices updated to the list typically included with QEMU. NOTE: The list of PCI devices for which we initialize PCI_INTERRUPT_LINE is hard-coded, and, depending on how QEMU devices are configured on the command line, may miss some devices, or (harmlessly) attempt to initialize devices which are not present in the system. A subsequent patch will replace this hard-coded list with a mechanism to correctly initialize PCI_INTERRUPT_LINE for applicable present PCI devices only. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16379 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: AcpiTimerLib: Switch additional stages to PCD-based Dxe instanceGabriel Somlo
Link DXE_SMM_DRIVER, UEFI_DRIVER, UEFI_APPLICATION, and SMM_CORE against a valid, non-asserting version of PcdLib, then switch them over to using the "Dxe" instance of AcpiTimerLib (instead of the "Base" version). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16378 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIMGabriel Somlo
Since in OVMF both PEI_CORE and PEIM run from RAM, and thus may utilize global variables, use the "Base" AcpiTimerLib instance (instead of BaseRom) to take advantage of the improved efficiency of storing the timer register IO address in a global variable. This leaves only SEC using the BaseRomAcpiTimerLib instance. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16377 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instancesGabriel Somlo
Remove local power management register access macros in favor of factored-out ones in OvmfPkg/Include/OvmfPlatforms.h Next, AcpiTimerLib is split out into three instances, for use during various stages: - BaseRom: used during SEC, PEI_CORE, and PEIM; - Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER; - Base: used by default during all other stages. Most of the code remains in AcpiTimerLib.c, to be shared by all instances. The two platform-dependent methods (constructor and InternalAcpiGetTimerTick) are provided separately by source files specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c. Since pre-DXE stages can't rely on storing data in global variables, methods specific to the "BaseRom" instance will call platform detection macros each time they're invoked. The "Base" instance calls platform detection macros only from its constructor, and caches the address required by InternalAcpiTimerTick in a global variable. The "Dxe" instance is very similar to "Base", except no platform detection macros are called at all; instead, the platform type is read via a dynamic PCD set from PlatformPei. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: drop custom boot timeout, revert to IntelFrameworkModulePkg'sLaszlo Ersek
PlatformBdsEnterFrontPage() already implements a keypress wait (for entering the setup utility at boot) with a nice progress bar, only OVMF has not been using it. Removing our custom code and utilizing PlatformBdsEnterFrontPage()'s builtin wait has the following benefits: - It simplifies OVMF's BDS code. - Because now we call PlatformBdsEnterFrontPage() unconditionally, it actually has a chance to look at the EFI_OS_INDICATIONS_BOOT_TO_FW_UI bit of the "OsIndications" variable, improving compliance with the UEFI specification. References: - https://bugzilla.redhat.com/show_bug.cgi?id=1153927 - http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10487 - The progress bar looks nice. (And it keeps the earlier behavior intact, when the user presses a key on the TianoCore splash screen.) In any case, we set the timeout to 0 (which doesn't show the progress bar and proceeds to the boot options immediately) in order to keep the boot time down. 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@16310 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: drop superfluous "connect first boot option" logicLaszlo Ersek
This is again obviated by our earlier BdsLibConnectAll() call. 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@16309 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: optimize second argument in PlatformBdsEnterFrontPage() callLaszlo Ersek
The second parameter of said function is "ConnectAllHappened", and if set to TRUE, the function sets "gConnectAllHappened" to TRUE. This global variable in turn controls whether Intel BDS code *itself* calls BdsLibConnectAllDriversToAllControllers() in various places -- if the indicator is TRUE, then the "connect all" is assumed to have been performed, and Intel BDS doesn't do it itself. OVMF should pass TRUE as "ConnectAllHappened", because a few lines before our call to PlatformBdsEnterFrontPage(), we already connect everything with BdsLibConnectAll(), which includes the effects of BdsLibConnectAllDriversToAllControllers(): PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c] BdsLibConnectAll() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsConnect.c] BdsLibConnectAllDriversToAllControllers() PlatformBdsEnterFrontPage() [IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c] 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@16308 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: don't overwrite the BDS Front Page timeoutLaszlo Ersek
The PlatformBdsEnterFrontPage() function's first parameter, "TimeoutDefault", determines the behavior of the setup utility: - If (TimeoutDefault == 0), then the usual boot order is to be acted upon immediately. - If (TimeoutDefault == 0xFFFF), then the setup utility is entered unconditionally. - If (0 < TimeoutDefault && TimeoutDefault < 0xFFFF), then the PlatformBdsEnterFrontPage() function displays a progress bar, waiting for TimeoutDefault seconds. If the user presses a key, then the setup utility is entered, otherwise the normal boot option processing takes place. The TimeoutDefault parameter is supposed to be set from gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut which has the following (matching) documentation in "IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec": The number of seconds that the firmware will wait before initiating the original default boot selection. A value of 0 indicates that the default boot selection is to be initiated immediately on boot. The value of 0xFFFF then firmware will wait for user input before booting. OVMF does this actually -- see the Timeout variable in PlatformBdsPolicyBehavior() -- but right before calling PlatformBdsEnterFrontPage(), OVMF hardwires TimeoutDefault to 0xFFFF. This has been acceptable until now, because OVMF implements its own "wait for keypress at the splash screen" logic in PlatformBdsPolicyBehavior(), completely avoiding the progress bar mentioned above. OVMF only calls PlatformBdsEnterFrontPage() when the user presses a key during its own "splash screen wait", and *then* it indeed makes sense to enter the setup utility unconditionally. However, even that way, the Timeout = 0xffff; assignment is superfluous, because 0xFFFF is already the default value of PcdPlatformBootTimeOut in "IntelFrameworkModulePkg.dec", and OvmfPkg doesn't override it in its DSC files. 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@16307 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: drop useless return statementLaszlo 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@16306 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-06OvmfPkg: BDS: remove dead call to PlatformBdsEnterFrontPage()Laszlo Ersek
This call has been dead since the conception of OvmfPkg (git commit 49ba9447 / SVN r8398), and only confuses readers -- let's remove it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16305 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg QemuFwCfgLib: Convert X64/IoLibExAsm.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert X64/IoLibExAsm.asm to X64/IoLibExAsm.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16290 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg QemuFwCfgLib: Convert Ia32/IoLibExAsm.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert Ia32/IoLibExAsm.asm to Ia32/IoLibExAsm.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16289 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg LoadLinuxLib: Convert X64/JumpToKernel.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert X64/JumpToKernel.asm to X64/JumpToKernel.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16288 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg LoadLinuxLib: Convert Ia32/JumpToKernel.asm to NASMJordan Justen
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert Ia32/JumpToKernel.asm to Ia32/JumpToKernel.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16287 6f19259b-4bc3-4df7-8a09-765794883524
2014-09-25OvmfPkg: Fix VS2005 build warningsJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16171 6f19259b-4bc3-4df7-8a09-765794883524
2014-09-09OvmfPkg: AcpiTimerLib: Access power mgmt regs based on host bridge typeGabriel Somlo
Pick the appropriate bus:dev.fn for accessing ACPI power management registers (00:01.3 on PIIX4 vs. 00:1f.0 on Q35) based on the device ID of the host bridge (assumed always present at 00:00.0). With this patch, OVMF can boot QEMU's "-machine q35" x86 machine type. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-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@16066 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-13Fix VS2013 build failure.Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15795 6f19259b-4bc3-4df7-8a09-765794883524
2014-06-19OvmgPkg: QemuFwCfgLib: export QEMU_FW_CFG_FNAME_SIZELaszlo Ersek
Names of firmware configuration files always take 56 bytes (including at least one terminating NUL byte). Expose this constant to all consumers of QemuFwCfgLib because further interfaces may depend on it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15571 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-31OvmfPkg: add a catch-all match for PCI devices in the OpenFirmware pathPaolo Bonzini
In many cases, the second node in /pci@i0cf8/XYZ@DD,FF node is enough to match a UEFI device path; a typical cases is a NIC that is assigned from the host to the guest. Add a catch-all case for PCI devices, and reuse it for NICs since it works well for those too. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15422 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-13OvmfPkg: BDS: QemuBootOrder: don't leak unreferenced boot optionsLaszlo Ersek
The Boot#### variables that have become unreferenced in the new BootOrder variable won't ever be automatically reused for booting. They are "unreachable" resources that take up room in the variable store. Make an effort to remove them. This should plug the leak which, given sufficient reboots, exhausts the variable store with stale Boot#### variables and renders the VM unbootable. Reported-by: Michael Chang <mchang@suse.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@15327 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-13OvmfPkg: BDS: remove historic (now defunct) boot mode hackLaszlo Ersek
When PI can distinguish the "full config" boot mode from "assume no changes", then the following BDS logic is correct: if BootMode == BOOT_WITH_FULL_CONFIGURATION: // // connect all devices // create & append each default boot option that's missing // BdsLibConnectAll BdsLibEnumerateAllBootOption else if BootMode == BOOT_ASSUMING_NO_CONFIGURATION_CHANGES: // // just stick with current BootOrder and the Boot#### variables // referenced by it // In theory, the first branch is intended to run infrequently, and the "assume no changes" branch should run most of the time. However, some platforms can't tell these two boot modes apart. The following substitute had been introduced: // // Technically, always assume "full config", but the BootMode HOB is // actually meaningless wrt. to "full config" or "assume no changes". // ASSERT (BootMode == BOOT_WITH_FULL_CONFIGURATION); // // Key off the existence of BootOrder. Try to prepare an in-memory list // of boot options, based on BootOrder and the referenced Boot#### // variables. // Status = BdsLibBuildOptionFromVar() // // If that succeeded, we'll treat it as "assume no changes". If it // failed (*only* if it failed), we'll build default boot options, // calling it "full config": // if EFI_ERROR(Status): BdsLibConnectAll() BdsLibEnumerateAllBootOption(BootOptionList) What we have now in OVMF is a mixture of the hack, and the behavior that's theoretically correct for "full config": - We assert "full config" -- this is OK. - We call "connect all" and "enumerate all" deliberately -- this is OK too. It matches "full config" which we assert. - However, we also have the hack in place, which had been meant as an alternative. In order to clean this up, we either need to restore the hack to its original form (ie. comment out the unconditional calls again), or we ought to remove the hack altogether. The unconditional "connect all" + "enumerate all" calls are the correct approach for OVMF, because we want, in fact, to start with "full config". The QEMU boot order specification and the set of emulated devices might change "out of band", which excludes "assume no changes". In other words, removing the hack corresponds to the "real production" case that the comment hints at. Because SetBootOrderFromQemu() may change the BootOrder NvVar, we must preserve the BdsLibBuildOptionFromVar() function call, in order to refresh the in-memory list with the new boot priorities. (The last step of BdsLibEnumerateAllBootOption() is such a call too.) 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@15326 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: implement LockBoxLibLaszlo Ersek
The S3 suspend/resume infrastructure depends on the LockBox library class. The edk2 tree currently contains Null and SMM instances. The Null instance is useless, and the SMM instance would require SMM emulation by including the SMM core and adding several new drivers, which is deemed too complex. Hence add a simple LockBoxLib instance for OVMF. jordan.l.justen@intel.com: * use PCDs instead of EmuNvramLib - clear memory in PlatformPei on non S3 boots * allocate NVS memory and store a pointer to that memory - reduces memory use at fixed locations Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15301 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg QemuFwCfgLib: determine if S3 support is explicitly enabledLaszlo Ersek
Such a packaged query function will come in handy in the following patches. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [jordan.l.justen@intel.com: check for enabled rather than disabled] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15292 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-09OvmfPkg: QemuBootOrder: initialize IsFinal variable to make MSVC happyMauro Faccenda
The BOOLEAN IsFinal variable initialization isn't properly seen by MSVC. To make it compile OVMF the variable needs to be initialized. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Mauro Faccenda <faccenda@gmail.com> Reviewed-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@15214 6f19259b-4bc3-4df7-8a09-765794883524
2014-01-29OvmfPkg: QemuBootOrder: handle QEMU's "-boot strict=on" optionLaszlo Ersek
When this option is passed to qemu, it appends the word HALT to the "bootorder" fw_cfg file, as last entry. For example, /pci@i0cf8/ethernet@3/ethernet-phy@0 /pci@i0cf8/scsi@4/disk@0,0 HALT The option's purpose is to prevent SeaBIOS from booting from devices that have not been specified explicitly (with bootindex=N device properties nor -boot options). When SeaBIOS sees HALT, it doesn't proceed to boot from default locations (after boot fails from all of the listed locations). The HALT string currently causes OVMF to reject the entire "bootorder" fw_cfg contents, with "parse error". This is not good, because since a recent libvirt commit, libvirt unconditionally passes "-boot strict=on" to qemu. Consequently, the boot order logic in QemuBootOrder.c has stopped working for libvirt users. OVMF's SetBootOrderFromQemu() function actually implements the idea behind "-boot strict=on": it drops all boot options not in the fw_cfg list. (*) Therefore, let's recognize HALT, and just do what we've been doing all along. (*) Except the UEFI shell, according to the survival policy in BootOrderComplete(), but the memory mapped UEFI shell is not expressible via fw_cfg anyway, and its preservation has been requested on edk2-devel. Hence it's a good boot option to keep in any case. 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@15197 6f19259b-4bc3-4df7-8a09-765794883524
2014-01-03OvmfPkg: QemuFwCfgLib: implement for SECLaszlo Ersek
The QemuFwCfgSecLib library instance - is stateless, - has no library constructor, - is available to SEC client code, - must be queried with QemuFwCfgIsAvailable() before use, - is restricted to SEC in order to limit the explicit querying requirement. (There is no current user.) 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@15046 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-18 10:20:27 +0000