Commit Graph

628 Commits

Author SHA1 Message Date
Paulo Alcantara 90721ba562 OvmfPkg/PlatformPei: Initialise RCBA (B0:D31:F0 0xf0) register
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-09 15:28:15 +00:00
Paulo Alcantara 589756c7a6 OvmfPkg/PlatformPei: Query Host Bridge DID only once
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-06-09 15:28:09 +00:00
Laszlo Ersek 93bbb0ed0b OvmfPkg: AcpiS3SaveDxe: fix protocol usage hint in the INF file
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-13 09:31:58 +00:00
Laszlo Ersek cc5e0aa9ca OvmfPkg: extract some bits and port offsets common to Q35 and I440FX
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-13 09:31:53 +00:00
Laszlo Ersek da37216768 OvmfPkg: consolidate POWER_MGMT_REGISTER_PIIX4() on "I440FxPiix4.h" macros
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-13 09:31:49 +00:00
Laszlo Ersek bc9d05d6f2 OvmfPkg: consolidate POWER_MGMT_REGISTER_Q35() on "Q35MchIch9.h" macros
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-13 09:31:44 +00:00
Laszlo Ersek 6b225ace4b OvmfPkg: new macros for platform specific register addresses and values
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-13 09:31:39 +00:00
Laszlo Ersek cb2e300766 OvmfPkg: split Include/OvmfPlatforms.h
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-13 09:31:10 +00:00
Laszlo Ersek feca17fa4b OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridges
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-08 18:12:44 +00:00
Ruiyu Ni 86a9c7a74d OvmfPkg: Use the new PCDs defined in MdePkg and MdeModulePkg.
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-05-06 03:27:42 +00:00
Jordan Justen 9b8e414880 OvmfPkg/XenBusDxe: Fix build issue with VS2010
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-01 08:23:11 +00:00
Jordan Justen 5f239ef794 OvmfPkg/SmbiosPlatformDxe: Fix build issue with VS2010
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-04-01 08:23:01 +00:00
Ard Biesheuvel c6d2972645 OvmfPkg: XenConsoleSerialPortLib: deal with output overflow
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-27 21:25:16 +00:00
Gabriel Somlo e2ab3f819f OvmfPkg: Q35: Use correct ACPI PM control register:bit
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-26 19:06:07 +00:00
Laszlo Ersek 47e57f4f5f OvmfPkg: include XHCI driver
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-16 19:57:34 +00:00
Laszlo Ersek 48b3ff0479 OvmfPkg: replace strict XenHypercallLib construction with explicit query
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-03 08:13:40 +00:00
Laszlo Ersek 02f69a25f0 OvmfPkg: XenHypercallLib: introduce XenHypercallIsAvailable()
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-03 08:13:30 +00:00
Laszlo Ersek b5d85f6221 OvmfPkg: XenHypercallLib: add empty constructor for ARM & AARCH64
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-03 08:13:19 +00:00
Laszlo Ersek df040c00ae OvmfPkg, ArmVirtualizationPkg: clean up XenHypercallLib names
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-03-03 08:13:09 +00:00
Ard Biesheuvel 0169352eaa ArmVirtualizationPkg: add XenIoMmioLib
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-28 20:34:16 +00:00
Ard Biesheuvel b0022ab871 Ovfm/Xen: add a Vendor Hardware device path GUID for the XenBus root
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-28 20:34:06 +00:00
Ard Biesheuvel d401a48741 Ovmf/Xen: add Xen PV console SerialPortLib driver
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-28 20:33:45 +00:00
Ard Biesheuvel e482753b33 Ovmf/Xen: port XenBusDxe to other architectures
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-28 20:33:34 +00:00
Ard Biesheuvel b94c3ac93d Ovmf/Xen: implement XenHypercallLib for ARM
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-28 20:33:22 +00:00
Ard Biesheuvel d9fdfd851a Ovmf/Xen: move XenBusDxe to abstract XENIO_PROTOCOL
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-28 20:33:11 +00:00
Ard Biesheuvel f2162d3410 Ovmf/Xen: add separate driver for Xen PCI device
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-28 20:33:00 +00:00
Ard Biesheuvel b2165af423 Ovmf/Xen: introduce XENIO_PROTOCOL
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-28 20:32:50 +00:00
Ard Biesheuvel cd8ff8fdda Ovmf/Xen: move XenBusDxe hypercall code to separate library
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-28 20:32:39 +00:00
Ard Biesheuvel bbc3758ab5 Ovmf/Xen: refactor XenBusDxe hypercall implementation
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-28 20:32:27 +00:00
Ard Biesheuvel d6970b9b41 Ovmf/Xen: fix pointer to int cast in XenBusDxe
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-28 20:32:16 +00:00
Ard Biesheuvel 0ac10d1d8e Ovmf/Xen: move Xen interface version to <xen.h>
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-28 20:32:06 +00:00
Laszlo Ersek 84a75f70e9 OvmfPkg/QemuVideoDxe: enable ARM builds
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-23 16:02:29 +00:00
Laszlo Ersek 818bc86aa7 OvmfPkg: AcpiPlatformDxe: make dependency on PCI enumeration dynamic
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-19 23:46:27 +00:00
Laszlo Ersek 04951644cd OvmfPkg: AcpiPlatformDxe: extract common entry point
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-19 23:45:57 +00:00
Jordan Justen f186536bdd OvmfPkg/AcpiPlatformDxe: InstallAllQemuLinkedTables => InstallQemuFwCfgTables
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-19 23:45:50 +00:00
Jordan Justen b70c4d07f3 OvmfPkg/AcpiPlatformDxe: FindAcpiTablesInFv => InstallOvmfFvTables
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-19 23:45:42 +00:00
Jordan Justen 53596a72cd OvmfPkg/AcpiPlatformDxe: Assert if AcpiTable protocol is not found
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-17 18:58:05 +00:00
Jordan Justen 903f52297f OvmfPkg/QemuFwCfgAcpiPlatformDxe: Move entry point to QemuFwCfgAcpi.c
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-17 00:14:58 +00:00
Andrew Fish cbe2e9ee55 OvmfPkg/build.sh: Use XCODE5 for newer OS X releases
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-17 00:05:41 +00:00
Jordan Justen 28a34033ee OvmfPkg/PlatformBdsLib: Signal ReadyToBoot before booting QEMU kernel
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-17 00:05:36 +00:00
Jordan Justen 0d696b789f OvmfPkg/build.sh: Allow qemu parameters with spaces
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-17 00:05:31 +00:00
Gabriel Somlo 2425674438 OvmfPkg/SMBIOS: Provide default Type 0 (BIOS Information) structure
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-13 19:50:05 +00:00
Liming Gao 5e795f936f OvmfPkg: Update PlatformBaseDebugLibIoPort library
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-06 06:38:37 +00:00
Jordan Justen 9a426abcdb OvmfPkg: Update web page and wiki urls
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-05 18:24:38 +00:00
Jordan Justen 3f3c4895da */Contributions.txt: Update example email address
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-03 17:29:14 +00:00
Jordan Justen 48b850898b OvmfPkg/AcpiPlatformDxe: Add QEMU fw-cfg only driver
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-02 19:09:02 +00:00
Jordan Justen 14b0faadfc OvmfPkg/AcpiPlatformDxe: Split QEMU fw-cfg into a new file
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-02-02 19:08:57 +00:00
Laszlo Ersek ea444a3e42 OvmfPkg: PlatformBdsLib: get front page timeout from QEMU
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-14 16:25:59 +00:00
Laszlo Ersek 9253c14d41 OvmfPkg: QemuBootOrderLib: expose QEMU's "-boot menu=on[,splash-time=N]"
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-14 16:25:54 +00:00
Daryl McDaniel ae591c14b3 MdeModulePkg, MdePkg, NetworkPkg, OvmfPkg, PerformancePkg, ShellPkg: Library 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-13 01:04:07 +00:00