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>
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>
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>
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>
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>
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 initialization of PCI_INTERRUPT_LINE registers *should*
be accomplished programmatically by enumerating all PCI devices
present in the system and computing PCI_INTERRUPT_LINE from
PCI_INTERRUPT_PIN, the slot/position of the device, and the available
host IRQs (for an example, see SeaBIOS pci_bios_init_devices() in
src/fw/pciinit.c). At the time of this patch, the relevant bits of
OVMF PCI initialization are shown in the following call tree:

  PlatformBdsPolicyBehavior ()
  {
    ...
    ConnectRootBridge ()
    {
      ...
      gBS->ConnectController ()  // PCI bus is enumerated from this call
      ...
    }
    ...
    PlatformBdsConnectSequence ()
    {
      ...
      PciAcpiInitialization ()  // PCI initialization affected by this patch
      ...
    }
    ...
  }

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>