summaryrefslogtreecommitdiff
path: root/OvmfPkg
AgeCommit message (Collapse)Author
2015-05-13OvmfPkg: AcpiS3SaveDxe: fix protocol usage hint in the INF fileLaszlo Ersek
SVN r15305 (git 5a217a06), "OvmfPkg: S3 Suspend: save boot script after ACPI context", made this driver install gEfiDxeSmmReadyToLockProtocolGuid in SaveS3BootScript() -- for valid reasons --, however in the INF file the protocol was marked as "ALWAYS_CONSUMED". Fix 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@17437 6f19259b-4bc3-4df7-8a09-765794883524
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-13OvmfPkg: new macros for platform specific register addresses and valuesLaszlo Ersek
Define some new macros for register addresses (both PCI and IO) and register values (bits) that we're going to use soon. 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@17433 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: split Include/OvmfPlatforms.hLaszlo Ersek
Move platform specific macros to their own include 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@17432 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-04-01OvmfPkg/XenBusDxe: Fix build issue with VS2010Jordan Justen
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@17091 6f19259b-4bc3-4df7-8a09-765794883524
2015-04-01OvmfPkg/SmbiosPlatformDxe: Fix build issue with VS2010Jordan Justen
VS2010 doesn't accept an unsized array within a structure. 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@17090 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-16OvmfPkg: include XHCI driverLaszlo Ersek
QEMU commit aa685789 ("xhci: generate a Transfer Event for each Transfer TRB with the IOC bit set") fixed an emulation problem in QEMU; we can now drive that host controller with edk2's XhciDxe. Include it in OvmfPkg, as XHCI emulation is reportedly more virtualization-friendly than EHCI, consuming less CPU. The driver can be tested with the following QEMU command line options: -device nec-usb-xhci -device usb-kbd This patch should not regress existing QEMU command lines (ie. trigger an ASSERT() in XhciDxe that fails on pre-aa685789 QEMU) because QEMU's "-device nec-usb-xhci" has never before resulted in USB devices that worked with edk2 firmware builds, hence users have never had a reason to add that option. Now that they learn about XHCI support in OVMF by reading this commit message, they (or their packagers) will also know to update qemu to aa685789 or later (in practice that means the upcoming 2.3 release), at least if they want to use '-device nec-usb-xhci' with edk2, for the first time ever. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Alexander Graf <agraf@suse.de> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17055 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-28Ovfm/Xen: add a Vendor Hardware device path GUID for the XenBus rootArd Biesheuvel
On non-PCI Xen guests (such as ARM), the XenBus root is not a PCI device but an abstract 'platform' device. Add a dedicated Vendor Hardware device path GUID to identify this node. 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@16978 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: port XenBusDxe to other architecturesArd Biesheuvel
This patch updates XenBusDxe to use the 16-bit compare and exchange function that was introduced for this purpose to the BaseSynchronizationLib. It also provides a new generic implementation of TestAndClearBit () using the same 16-bit compare and exchange, making this module fully architecture agnostic. Contributed-under: TianoCore Contribution Agreement 1.0 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@16975 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 to abstract XENIO_PROTOCOLArd Biesheuvel
While Xen on Intel uses a virtual PCI device to communicate the base address of the grant table, the ARM implementation uses a DT node, which is fundamentally incompatible with the way XenBusDxe is implemented, i.e., as a UEFI Driver Model implementation for a PCI device. Contributed-under: TianoCore Contribution Agreement 1.0 Acked-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@16973 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: add separate driver for Xen PCI deviceArd Biesheuvel
Prepare for making XenBusDxe suitable for use with non-PCI devices (such as the DT node exposed by Xen on ARM) by introducing a separate DXE driver that binds to the Xen virtual PCI device and exposes the abstract XENIO_PROTOCOL for XenBusDxe to bind against. 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@16972 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: introduce XENIO_PROTOCOLArd Biesheuvel
This introduces the abstract XENIO_PROTOCOL that will be used to communicate the Xen grant table address to drivers supporting this protocol. Primary purpose is allowing us to change the XenBusDxe implementation so that it can support non-PCI Xen implementations such as Xen on ARM. 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@16971 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-28Ovmf/Xen: refactor XenBusDxe hypercall implementationArd Biesheuvel
This refactors the Xen hypercall implementation that is part of the XenBusDxe driver, in preparation of splitting it off entirely into a XenHypercallLib library. This involves: - removing the dependency on XENBUS_DEVICE* pointers in the XenHypercall() prototypes - moving the discovered hyperpage address to a global variable - moving XenGetSharedInfoPage() to its only user XenBusDxe.c (the shared info page is not strictly part of the Xen hypercall interface, and is not used by other expected users of XenHypercallLib such as the Xen console version of SerialPortLib - reimplement XenHypercall2() in C and move the indexing of the hyperpage there; the existing asm implementations are renamed to __XenHypercall2() and invoked from the new C implementation. Contributed-under: TianoCore Contribution Agreement 1.0 Acked-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@16969 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: fix pointer to int cast in XenBusDxeArd Biesheuvel
On ARM, xen_pfn_t is 64 bits but the size of a pointer is only 32 bits, so casting between them needs to go via (UINTN). Also move the xen_pfn_t cast outside the shift so that we can avoid shifting 64-bit quantities on 32-bit architectures, which may require runtime library support. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> 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@16968 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: move Xen interface version to <xen.h>Ard Biesheuvel
Tiancore has its private copy of the Xen headers, and all drivers that depend on it should use the same Xen interface version, so let's move the #define to xen.h itself. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-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@16967 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-23OvmfPkg/QemuVideoDxe: enable ARM buildsLaszlo Ersek
The only feature not portable to ArmVirtualizationQemu is the VBE shim; make that dependent on Ia32 / X64. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Olivier Martin <Olivier.martin@arm.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16890 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-19OvmfPkg: AcpiPlatformDxe: make dependency on PCI enumeration dynamicLaszlo Ersek
SVN r16411 delayed ACPI table installation until PCI enumeration was complete, because on QEMU the ACPI-related fw_cfg files should have been downloaded only after PCI enumeration. Said commit implemented the dependency by tightening the module's depex. This patch replaces the EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL depex with a matching protocol registration callback. The depex was static, and it could not handle dynamically discovered situations when the dependency would turn out invalid. Namely: - At the moment, the depex in "QemuFwCfgAcpiPlatformDxe.inf" assumes that "ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc" lacks PCI support. However, PCI support is about to become run-time discoverable on that platform. If PCI support is missing, then ArmVirtualizationPkg will set PcdPciDisableBusEnumeration to TRUE. Hence, when PcdPciDisableBusEnumeration is TRUE, we invalidate the dependency by not registering the callback and installing the ACPI tables right away. - InitializeXen() in "OvmfPkg/PlatformPei/Xen.c" sets PcdPciDisableBusEnumeration to TRUE. This causes PciBusDriverBindingStart() in "MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c" to set gFullEnumeration to FALSE, which in turn makes PciEnumerator() in "MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c" branch to PciEnumeratorLight(). The installation of EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL at the end of PciEnumerator() is not reached. Which means that starting with SVN r16411, AcpiPlatformDxe is never dispatched on Xen. Hence, when PcdPciDisableBusEnumeration is TRUE, we invalidate the dependency by not registering the callback and installing the ACPI tables right away. 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: Removed PcdOvmfPciEnabled] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16887 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-19OvmfPkg: AcpiPlatformDxe: extract common entry pointLaszlo Ersek
Currently the entry point functions of both driver builds (AcpiPlatformDxe.inf and QemuFwCfgAcpiPlatformDxe.inf) directly contain the logic that is different between the two builds. Because we're going to restructure the entry point logic soon, we'd have to duplicate the same new code between both entry point functions. Push down the logic in which they differ to a new function: - InstallAcpiTables() [AcpiPlatform.c] - InstallAcpiTables() [QemuFwCfgAcpiPlatform.c] and extract a common entry point function: - AcpiPlatformEntryPoint() [EntryPoint.c] which we can soon modify without code duplication. 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@16885 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-19OvmfPkg/AcpiPlatformDxe: InstallAllQemuLinkedTables => InstallQemuFwCfgTablesJordan Justen
This name better aligns with InstallXenTables and InstallOvmfFvTables. 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@16884 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-19OvmfPkg/AcpiPlatformDxe: FindAcpiTablesInFv => InstallOvmfFvTablesJordan Justen
Since this function also installs the tables, this is a better name. It also aligns with the InstallXenTables name. 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@16883 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-17OvmfPkg/AcpiPlatformDxe: Assert if AcpiTable protocol is not foundJordan Justen
Since the protocol is in the depex, there is no reason to expect we might fail to locate the protocol. 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@16882 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-17OvmfPkg/QemuFwCfgAcpiPlatformDxe: Move entry point to QemuFwCfgAcpi.cJordan Justen
Having this entry point in QemuFwCfgAcpi.c should not cause a problem for the other driver which supports Xen and older QEMU versions. 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@16880 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-17OvmfPkg/build.sh: Use XCODE5 for newer OS X releasesAndrew Fish
Update OS Major number checking to future proof it, and default to XCODE5 (clang + lldb). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Andrew Fish <afish@apple.com> Reviewed-by: Bruce Cran <bruce.cran@gmail.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16879 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-17OvmfPkg/build.sh: Allow qemu parameters with spacesJordan Justen
This change allows QEMU parameters to have spaces. For example: OvmfPkg/build.sh qemu -kernel vmlinuz -append "kernel-param1 param2" 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@16877 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-13OvmfPkg/SMBIOS: Provide default Type 0 (BIOS Information) structureGabriel Somlo
Insert a default, OVMF-specific Type 0 (BIOS Information) structure into the SMBIOS table, unless the underlying guest VM supplies its own, overriding instance. As an example, QEMU, while allowing the user to specifically force generation of a Type 0 structure, will not generate one by default, considering that task to be the responsibility of the BIOS itself. Based on an earlier out-of-tree patch by Laszlo Ersek <lersek@redhat.com> 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@16868 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-02-05OvmfPkg: Update web page and wiki urlsJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Bruce Cran <bruce.cran@gmail.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16778 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-03*/Contributions.txt: Update example email addressJordan Justen
Use the example.com domain as recommended in RFC 2606. NOTE: This does not modify the wording of the "TianoCore Contribution Agreement 1.0" section Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Bruce Cran <bruce.cran@gmail.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16724 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-02OvmfPkg/AcpiPlatformDxe: Add QEMU fw-cfg only driverJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16697 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-02OvmfPkg/AcpiPlatformDxe: Split QEMU fw-cfg into a new fileJordan Justen
The code left behind in Qemu.c has some PCAT dependencies, and might not be able to build on all platforms. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16696 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-13MdeModulePkg, MdePkg, NetworkPkg, OvmfPkg, PerformancePkg, ShellPkg: Library ↵Daryl McDaniel
Migration. Move libraries from ShellPkg into MdeModulePkg and MdePkg. The following libraries are being migrated out of ShellPkg in order to make their functionality more widely available. • PathLib: Incorporate into MdePkg/Library/BaseLib • FileHandleLib: MdePkg/Library/UefiFileHandleLib • BaseSortLib: MdeModulePkg/Library/BaseSortLib • UefiSortLib: MdeModulePkg/Library/UefiSortLib Diffs showing file changes are in the attached file, LibMigration.patch. A description of the changes follows: • Move ShellPkg/Include/Library/FileHandleLib.h to MdePkg/Include/Library/FileHandleLib.h • Move ShellPkg/Include/Library/SortLib.h to MdeModulePkg/Include/Library/SortLib.h • Move ShellPkg/Library/BaseSortLib to MdeModulePkg/Library/BaseSortLib • Move ShellPkg/Library/UefiSortLib to MdeModulePkg/Library/UefiSortLib • Move ShellPkg/Library/BasePathLib/BasePathLib.c to MdePkg/Library/BaseLib/FilePaths.c • Merge ShellPkg/Include/Library/PathLib.h into MdePkg/Include/Library/BaseLib.h • Delete ShellPkg/Library/BasePathLib; Includes BasePathLib.c and BasePathLib.inf • NetworkPkg/NetworkPkg.dsc • PerformancePkg.dsc • OvmfPkg/OvmfPkgX64.dsc • OvmfPkg/OvmfPkgIa32X64.dsc • OvmfPkg/OvmfPkgIa32.dsc o Update SortLib and FileHandleLib library classes to point to the new library locations. o Remove PathLib library class and make sure that BaseLib is described. • MdeModulePkg/MdeModulePkg.dec o Add SortLib library class • MdePkg/MdePkg.dec o Add FileHandleLib library class o Add PcdUefiFileHandleLibPrintBufferSize PCD • MdePkg/Library/BaseLib/BaseLib.inf o Add FilePaths.c to [Sources] • MdePkg/Include/Library/BaseLib.h o Update file description to include "file path functions" • ShellPkg/ShellPkg.dsc o Change PACKAGE_GUID to { C1014BB7-4092-43D4-984F-0738EB424DBF } o Update PACKAGE_VERSION to 1.0 o Update SortLib and FileHandleLib library classes to point to the new library locations. o Remove PathLib library class and make sure that BaseLib is described. o Remove ShellPkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf from [Components] • ShellPkg/ShellPkg.dec o Update PLATFORM_VERSION to 1.0 o Remove declarations of the FileHandleLib, SortLib, and PathLib Library Classes o Update comment for the PcdShellPrintBufferSize PCD. • ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf • ShellPkg/Application/Shell/Shell.inf o Remove PathLib from [LibraryClasses] • ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h • ShellPkg/Application/Shell/Shell.h o Remove #include <Library/PathLib.h> • ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf o Add PathLib to [LibraryClasses] • ShellPkg/Library/UefiShellLevel1CommandsLib/If.c o Remove #include <Library/PathLib.h> • ShellPkg/Application/ShellSortTestApp/ShellSortTestApp.inf o Add MdeModulePkg/MdeModulePkg.dec to [Packages] • MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf • MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf o Replace ShellPkg.dec with MdeModulePkg.dec in [Packages] • MdeModulePkg/Library/UefiSortLib/UefiSortLib.c o Remove #include <ShellBase.h> o Define USL_FREE_NON_NULL() to replace SHELL_FREE_NON_NULL() Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Daryl McDaniel <daryl.mcdaniel@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16601 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
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-29 04:58:17 +0000