OvmfPkg: Factor out platform detection (q35 vs. piix4)

Introduce macros to detect the underlying platform and access its
ACPI power management registers, based on querying the host bridge
device ID.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
OvmfPkg: PlatformPei: Platform specific ACPI power management setup

Set up ACPI power management using registers determined based on
the underlying (PIIX4 or Q35/MCH) platform type.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
OvmfPkg: Add PCD for Host Bridge dev. ID (PcdOvmfHostBridgePciDevId)

Set from PEI, this PCD allows subsequent stages (specifically
DXE_DRIVER and DXE_RUNTIME_DRIVER) to infer the underlying platform
type (e.g. PIIX4 or Q35/MCH) without the need to further query the
Host Bridge for its Device ID.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
OvmfPkg: CsmSupportLib: Set/use platform specific legacy interrupt device

Use a PCD set from PEI to determine the legacy interrupt device
number appropriate for the underlying platform type during protocol
initialization.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instances

Remove local power management register access macros in favor of
factored-out ones in OvmfPkg/Include/OvmfPlatforms.h

Next, AcpiTimerLib is split out into three instances, for use during
various stages:

  - BaseRom: used during SEC, PEI_CORE, and PEIM;
  - Dxe:     used during DXE_DRIVER and DXE_RUNTIME_DRIVER;
  - Base:    used by default during all other stages.

Most of the code remains in AcpiTimerLib.c, to be shared by all
instances. The two platform-dependent methods (constructor and
InternalAcpiGetTimerTick) are provided separately by source files
specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c.

Since pre-DXE stages can't rely on storing data in global variables,
methods specific to the "BaseRom" instance will call platform
detection macros each time they're invoked.

The "Base" instance calls platform detection macros only from its
constructor, and caches the address required by InternalAcpiTimerTick
in a global variable.

The "Dxe" instance is very similar to "Base", except no platform
detection macros are called at all; instead, the platform type is
read via a dynamic PCD set from PlatformPei.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

Since in OVMF both PEI_CORE and PEIM run from RAM, and thus may
utilize global variables, use the "Base" AcpiTimerLib instance
(instead of BaseRom) to take advantage of the improved efficiency
of storing the timer register IO address in a global variable.

This leaves only SEC using the BaseRomAcpiTimerLib instance.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
OvmfPkg: AcpiTimerLib: Switch additional stages to PCD-based Dxe instance

Link DXE_SMM_DRIVER, UEFI_DRIVER, UEFI_APPLICATION, and SMM_CORE against
a valid, non-asserting version of PcdLib, then switch them over to using
the "Dxe" instance of AcpiTimerLib (instead of the "Base" version).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
OvmfPkg: PlatformBdsLib: Platform dependent PCI/IRQ initialization

Merge PciInitialization() and AcpiInitialization() into a single
function, PciAcpiInitialization(), and use a PCD set during PEI to
detect the underlying platform type (PIIX4 or Q35/MCH) and therefore
the addresses of the registers to be initialized.

Add LNK[A-H] routing target initialization for the Q35 platform.

Additionally, initialize PCI_INTERRUPT_LINE registers for the typical
set of PCI devices included by QEMU with the Q35 machine type. The
corresponding PIIX4 initialization of PCI_INTERRUPT_LINE registers is
cleaned up and the list of PIIX4 PCI devices updated to the list
typically included with QEMU.

NOTE: The list of PCI devices for which we initialize PCI_INTERRUPT_LINE
is hard-coded, and, depending on how QEMU devices are configured on
the command line, may miss some devices, or (harmlessly) attempt to
initialize devices which are not present in the system. A subsequent
patch will replace this hard-coded list with a mechanism to correctly
initialize PCI_INTERRUPT_LINE for applicable present PCI devices only.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
OvmfPkg: PlatformBdsLib: Dynamic PCI Interrupt Line register setup

Remove hard-coded list of PCI devices for which the Interrupt Line
register is initialized. Instead, provide a "visitor" function to
initialize the register only for present and applicable PCI devices.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>