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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Laszlo Ersek
Paulo Alcantara
Ruiyu Ni
Jordan Justen
Ard Biesheuvel
Gabriel Somlo
Andrew Fish
Liming Gao