OvmfPkg: PlatformPei: lifecycle fixes for the LockBox area

If (mBootMode == BOOT_ON_S3_RESUME) -- that is, we are resuming --, then
the patch has no observable effect.

If (mBootMode != BOOT_ON_S3_RESUME && mS3Supported) -- that is, we are
booting or rebooting, and S3 is supported), then the patch has no
observable effect either.

If (mBootMode != BOOT_ON_S3_RESUME && !mS3Supported) -- that is, we are
booting or rebooting, and S3 is unsupported), then the patch effects the
following two fixes:

- The LockBox storage is reserved from DXE (but not the OS). Drivers in
  DXE may save data in the LockBox regardless of S3 support, potentially
  corrupting any overlapping allocations. Make sure there's no overlap.

- The LockBox storage is cleared. A LockBox inherited across a non-resume
  reboot, populated with well-known GUIDs, breaks drivers that want to
  save entries with those GUIDs.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Matt Fleming <matt.fleming@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15418 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: AcpiS3SaveDxe: do not load if S3 is unsupported/disabled in qemu

The previous patch ensures that the LockBox is protected during DXE (but
the OS can still drop it) if S3 is unsupported or disabled. However, S3
related drivers not only save data in the lockbox, they allocate objects
with Reserved and AcpiNVS memory types too, which the OS can't (must not)
release. This is a waste when S3 is unsupported or disabled.

In OVMF a good "choke point" for these drivers is the entry point of
AcpiS3SaveDxe. The messages of the following commits are relevant to the
data and control flow:

- SVN r15290 (git commit 8f5ca05b)
- SVN r15305 (git commit 5a217a06)
- SVN r15306 (git commit d4ba06df)

Prevent AcpiS3SaveDxe from loading when S3 is unsupported or disabled.
This should keep away (most of the) dependent drivers too.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Matt Fleming <matt.fleming@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15419 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: AcpiPlatformDxe: download ACPI tables from QEMU

Recent qemu versions compose all ACPI tables on the host side, according
to the target hardware configuration, and make the tables available to any
guest firmware over fw_cfg.

See version compatibility information below.

The feature moves the burden of keeping ACPI tables up-to-date from boot
firmware to qemu (which is the source of hardware configuration anyway).

This patch adds client code for this feature. Benefits of the
qemu-provided ACPI tables include PCI hotplug for example.

Qemu provides the following three fw_cfg files:
- etc/acpi/rsdp
- etc/acpi/tables
- etc/table-loader

"etc/acpi/rsdp" and "etc/acpi/tables" are similar, they are only kept
separate because they have different allocation requirements in SeaBIOS.

Both of these fw_cfg files contain preformatted ACPI payload.
"etc/acpi/rsdp" contains only the RSDP table, while "etc/acpi/tables"
contains all other tables, concatenated.

The tables in these two fw_cfg files are filled in by qemu, but two kinds
of fields are left incomplete in each table: pointers to other tables, and
checksums (which depend on the pointers).

Qemu initializes each pointer with a relative offset into the fw_cfg file
that contains the pointed-to ACPI table. The final pointer values depend
on where the fw_cfg files, holding the pointed-to ACPI tables, will be
placed in memory by the guest. That is, the pointer fields need to be
"relocated" (incremented) by the base addresses of where "/etc/acpi/rsdp"
and "/etc/acpi/tables" will be placed in guest memory.

This is where the third file, "/etc/table-loader" comes in the picture. It
is a linker/loader script that has several command types:

  One command type instructs the guest to download the other two files.

  Another command type instructs the guest to increment ("absolutize") a
  pointer field (having a relative initial value) in the pointing ACPI
  table, present in some fw_cfg file, with the dynamic base address of the
  same (or another) fw_cfg file, holding the pointed-to ACPI table.

  The third command type instructs the guest to compute checksums over
  ranges and to store them.

In edk2, EFI_ACPI_TABLE_PROTOCOL knows about table relationships -- it
handles linkage automatically when a table is installed. The protocol
takes care of checksumming too. RSDP is installed automatically. Hence we
only need to care about the "etc/acpi/tables" fw_cfg file, determining the
boundaries of each ACPI table inside it, and installing those tables.

Qemu compatibility information:

--------------+---------------------+-------------------------------------
 qemu version | qemu machine type   | effects of the patch
--------------+---------------------+-------------------------------------
 up to 1.6.x  | any pc-i440fx       | None. OVMF's built-in ACPI tables
              |                     | are used.
--------------+---------------------+-------------------------------------
 any          | up to pc-i440fx-1.6 | None. OVMF's built-in ACPI tables
              |                     | are used.
--------------+---------------------+-------------------------------------
 1.7.0        | pc-i440fx-1.7       | Potential guest OS crash, dependent
              | (default for 1.7.0) | on guest RAM size.
              |                     |
              |                     | DO NOT RUN OVMF on the (1.7.0,
              |                     | pc-i440fx-1.7) qemu / machine type
              |                     | combination.
--------------+---------------------+-------------------------------------
 1.7.1        | pc-i440fx-1.7       | OVMF downloads valid ACPI tables
              | (default for 1.7.1) | from qemu and passes them to the
              |                     | guest OS.
--------------+---------------------+-------------------------------------
 2.0.0-rc0    | pc-i440fx-1.7 or    | OVMF downloads valid ACPI tables
              | later               | from qemu and passes them to the
              |                     | guest OS.
 -------------+---------------------+-------------------------------------

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@15420 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: non-null PcdLib instance for the CSM VideoDxe

VideoDxe is a UEFI_DRIVER, so it has by default a null instance
of PcdLib.  It accesses two PCDs that are now dynamic
(gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution
and gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution).
Similar to r15362 (OvmfPkg: non-null PcdLib instance for
GraphicsConsoleDxe, 2014-03-22), we need to specify a non-null
instance of PcdLib.

This patch unbreaks the CSM VideoDxe module for OvmfPkg.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.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@15421 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: add a catch-all match for PCI devices in the OpenFirmware path

In many cases, the second node in /pci@i0cf8/XYZ@DD,FF node is enough
to match a UEFI device path; a typical cases is a NIC that is assigned
from the host to the guest.  Add a catch-all case for PCI devices, and
reuse it for NICs since it works well for those too.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15422 6f19259b-4bc3-4df7-8a09-765794883524
ShellPkg: Fix potential memory leak when failing to fully create a structure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-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@15423 6f19259b-4bc3-4df7-8a09-765794883524
ShellPkg: Allow opening of root drive nodes

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-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@15424 6f19259b-4bc3-4df7-8a09-765794883524