The following call tree exposes a bug in the lifetime (ie. too late
creation) of PciIoDevice->DevicePath. The bug can be triggered when
PciBusDxe is built into OVMF, with qemu/KVM device assignment of
a PCI-express device on the default 440FX machine type.  OVMF
correctly discovers that the device is PCIe and begins probing
extended configuration space for the device.  The root bridge
has no way to access extended config space and correctly errors,
sending us into the error reporting chain seen below.  It's
possible that this error path could also be reproduced on physical
hardware when a PCI-to-PCIe bridge is present.

GatherDeviceInfo() | GatherPpbInfo() | GatherP2CInfo() [MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c]
  CreatePciIoDevice()                                  [MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c]
    AllocateZeroPool()
    LocateCapabilityRegBlock()                         [MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c]
    PciIoDevice->IsPciExp = TRUE
    LocatePciExpressCapabilityRegBlock()               [MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c]
      PciIoConfigRead() via funcptr                    [MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c]
        RootBridgeIoPciRead() via funcptr              [PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c]
          FAILS
        REPORT_STATUS_CODE_WITH_DEVICE_PATH()          [MdePkg/Include/Library/ReportStatusCodeLib.h]
          ReportStatusCodeWithDevicePath()             [MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c]
            ASSERT (DevicePath != NULL) <--+
  CreatePciDevicePath()                    |           [MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c]
    sets PciIoDevice->DevicePath ----------+

In English:
- CreatePciIoDevice() allocates a zeroed out PCI_IO_DEVICE structure.
- PciIoConfigRead() tries to access the (extended) config space, and
  fails.
- PciIoConfigRead() wants to report a status code (read error) for the
  device path.
- Unfortuantely, PciIoDevice->DevicePath is still NULL at that point.
- The ASSERT() in ReportStatusCodeWithDevicePath() fires.

Fix it by moving CreatePciDevicePath() into CreatePciIoDevice(),
allowing PciIoDevice->DevicePath to be initialized before we
begin probing the device capabilities:

GatherDeviceInfo() | GatherPpbInfo() | GatherP2CInfo() [MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c]
  CreatePciIoDevice()                                  [MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c]
    AllocateZeroPool()
    CreatePciDevicePath()                              [MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c]
      sets PciIoDevice->DevicePath -----------+
    LocateCapabilityRegBlock()                |        [MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c]
    PciIoDevice->IsPciExp = TRUE              |
    LocatePciExpressCapabilityRegBlock()      |        [MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c]
      PciIoConfigRead() via funcptr           |        [MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c]
        RootBridgeIoPciRead() via funcptr     |        [PcAtChipsetPkg/PciHostBridgeDxe/PciRootBridgeIo.c]
          FAILS                               |
        REPORT_STATUS_CODE_WITH_DEVICE_PATH() |        [MdePkg/Include/Library/ReportStatusCodeLib.h]
          ReportStatusCodeWithDevicePath()    |        [MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c]
            ASSERT (DevicePath != NULL) <-----+

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15567 6f19259b-4bc3-4df7-8a09-765794883524
Fix GCC build fail.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong <eric.dong@intel.com>




git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15570 6f19259b-4bc3-4df7-8a09-765794883524
OvmgPkg: QemuFwCfgLib: export QEMU_FW_CFG_FNAME_SIZE

Names of firmware configuration files always take 56 bytes (including at
least one terminating NUL byte). Expose this constant to all consumers of
QemuFwCfgLib because further interfaces may depend on 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@15571 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: AcpiPlatformDxe: pass FwCfgFile to InstallQemuLinkedTables()

Split InstallQemuLinkedTables() in two:
- the function now takes the name of the fw_cfg file (from which ACPI
  tables are to be extracted) as a parameter,

- the new function InstallAllQemuLinkedTables() calls the former with
  fw_cfg file names, and cumulatively tracks the ACPI tables installed by
  all invocations of the former.

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@15572 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: AcpiPlatformDxe: exclude RSD PTR from QEMU's fw_cfg payload

In one of the next patches we'll start scanning all fw_cfg files that QEMU
advertises as carrying ACPI tables, not just "etc/acpi/tables".

The RSD PTR table is known to occur in the "etc/acpi/rsdp" fw_cfg file.
Since edk2 handles RSD PTR automatically, similarly to RSDT and XSDT,
let's exclude RSD PTR too from the manually installed tables.

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@15573 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: AcpiPlatformDxe: don't rely on unstable QEMU interface

The fw_cfg file "etc/acpi/tables" is not a stable guest interface -- QEMU
could rename it in the future, and/or introduce additional fw_cfg files
with ACPI payload. Only the higher-level "etc/table-loader" file is
considered stable, which contains a sequence of commands to assist
firmware with reading QEMU ACPI tables from the FwCfg interface.

Because edk2 provides publishing support for ACPI tables, OVMF only uses
the Allocate command to find the names of FwCfg files to read and publish
as ACPI tables.

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@15574 6f19259b-4bc3-4df7-8a09-765794883524