summaryrefslogtreecommitdiff
path: root/OvmfPkg
AgeCommit message (Collapse)Author
2015-06-23OvmfPkg: QemuVideoDxe: add virtio-vga supportGerd Hoffmann
Qemu commit c5d4dac ("virtio-vga: add virtio gpu device with vga compatibility") enables OVMF to drive the virtio-vga device: The vga compatibility part of virtio-vga is identical to the qemu standard vga, so supporting that is as easy as adding the PCI ID to the list. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> [lersek@redhat.com: subject fixup and QEMU commit reference in commit msg] Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17690 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-22OvmfPkg: PlatformPei: set SMBIOS entry point version dynamicallyLaszlo Ersek
Git commit 54753b60 (SVN r16870), "MdeModulePkg: Update SMBIOS revision to 3.0." changed PcdSmbiosVersion from 0x0208 to 0x0300. This controls the version number of the SMBIOS entry point table (and other things) that "MdeModulePkg/Universal/SmbiosDxe" installs. Alas, this change breaks older Linux guests, like RHEL-6 (up to RHEL-6.7); those are limited to 2.x (both in the guest kernel firmware driver, and in the dmidecode utility). The SMBIOS 3.0 entry point has a different GUID -- defined in UEFI 2.5 -- pointing to it in the UEFI Configuration Table, and guest kernels that lack upstream kernel commit e1ccbbc9d5 don't recognize it. The v2.1.0+ machine types of QEMU generate SMBIOS payload for the firmware to install. The payload includes the entry point table ("anchor" table). OvmfPkg/SmbiosPlatformDxe cannot install the anchor table (because that is the jurisdiction of the generic "MdeModulePkg/Universal/SmbiosDxe" driver); however, we can parse the entry point version from QEMU's anchor table, and instruct "MdeModulePkg/Universal/SmbiosDxe" to adhere to that version. On machine types older than v2.1.0, the feature is not available, but then, should anything in OVMF install SMBIOS tables, version 2.8 is simply safer / more widely supported than 3.0 -- hence the default 2.8 value for the dynamic PCD. We set the PCD in PlatformPei (when not on the S3 resume path), because that's an easy and certain way to set the PCD before a DXE driver reads it. This follows the example of PcdEmuVariableNvStoreReserved (which is read by EmuVariableFvbRuntimeDxe). RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1232876 Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17676 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-09OvmfPkg/PlatformPei: Initialise RCBA (B0:D31:F0 0xf0) registerPaulo Alcantara
This patch initialises root complex register block BAR in order to support TCO watchdog emulation features (e.g. reboot upon NO_REBOOT bit not set) on QEMU. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paulo Alcantara <pcacjr@zytor.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@17601 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-09OvmfPkg/PlatformPei: Query Host Bridge DID only oncePaulo Alcantara
Make HostBridgeDevId global so MemMapInitialization() can also use it to conditionally add RCRB MMIO address to HOB. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paulo Alcantara <pcacjr@zytor.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@17600 6f19259b-4bc3-4df7-8a09-765794883524
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