Commit Graph

5 Commits

Author SHA1 Message Date
Laszlo Ersek fe4049471b OvmfPkg/PciHotPlugInitDxe: translate QEMU's resource reservation hints
Parse QEMU_PCI_BRIDGE_CAPABILITY_RESOURCE_RESERVATION from the bridges'
conventional config spaces. Translate the fields as follows:

* BusNumbers:
  * 0 -- no reservation;
  * (-1) -- firmware default, i.e. no reservation;
  * otherwise -- reserve the requested value. (NB, bus number reservation
    is not supposed to work before
    <https://bugzilla.tianocore.org/show_bug.cgi?id=656> is fixed.)

* Io:
  * 0 -- no reservation;
  * (-1) -- keep our current default (512B);
  * otherwise -- round up the requested value and reserve that.

* NonPrefetchable32BitMmio:
  * 0 -- no reservation;
  * (-1) -- keep our current default (2MB);
  * otherwise -- round up the requested value and reserve that.

* Prefetchable32BitMmio:
  * 0 -- no reservation, proceed to Prefetchable64BitMmio;
  * (-1) -- firmware default, i.e. no reservation, proceed to
    Prefetchable64BitMmio;
  * otherwise -- round up the requested value and reserve that. (NB, if
    Prefetchable32BitMmio is reserved in addition to
    NonPrefetchable32BitMmio, then PciBusDxe currently runs into an
    assertion failure. Refer to
    <https://bugzilla.tianocore.org/show_bug.cgi?id=720>.)

* Prefetchable64BitMmio:
  * only reached if Prefetchable32BitMmio was not reserved;
  * 0 -- no reservation;
  * (-1) -- firmware default, i.e. no reservation;
  * otherwise -- round up the requested value and reserve that.

If QEMU_PCI_BRIDGE_CAPABILITY_RESOURCE_RESERVATION is missing, plus any
time the rounding fails, fall back to the current defaults.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-10-03 16:07:39 +02:00
Laszlo Ersek 4776d5cb3a OvmfPkg/PciHotPlugInitDxe: add helper functions for setting up paddings
Extract the SetIoPadding() and SetMmioPadding() functions, so that we can
set EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR fields using parameter names and
values that are more friendly than the original field names and their
expected values.

Introduce the HighBitSetRoundUp32() and HighBitSetRoundUp64() functions
for calculating the last parameter ("SizeExponent") of SetIoPadding() and
SetMmioPadding().

Put the new functions to use when requesting the default reservations. (In
order to be consistent with a later patch, "SizeExponent" is calculated
for SetIoPadding() with HighBitSetRoundUp64().)

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-10-03 16:07:37 +02:00
Laszlo Ersek a980324709 OvmfPkg/PciHotPlugInitDxe: generalize RESOURCE_PADDING composition
PciHotPlugInitDxe has a static variable called "mPadding" (of type
RESOURCE_PADDING), which describes two constant resource reservations:

- MmioPadding: 2MB of non-prefetchable (hence 32-bit) MMIO space,

- IoPadding: 512B of IO space.

In the GetResourcePadding() member function of
EFI_PCI_HOT_PLUG_INIT_PROTOCOL, the driver outputs a dynamically allocated
verbatim copy of "mPadding", for PciBusDxe to consume in its
ApplyResourcePadding() function.

In a later patch, we're going to compose the set of resource reservations
dynamically, based on QEMU hints. Generalize the RESOURCE_PADDING
structure so that we may generate (or not generate) each resource type
individually:

- Replace the named "MmioPadding" and "IoPadding" fields in
  RESOURCE_PADDING with an array of descriptors,

- remove "mPadding",

- in GetResourcePadding(), request the same (default) reservations as
  before, as if we attempted and failed to fetch the QEMU hints.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-10-03 16:07:35 +02:00
Laszlo Ersek c18ac9fbcc OvmfPkg/PciHotPlugInitDxe: clean up addr. range for non-prefetchable MMIO
The non-prefetchable MMIO aperture of a bridge can never fall outside of
the 32-bit address space. Namely, the MemoryBase and MemoryLimit fields in
PCI_BRIDGE_CONTROL_REGISTER have type UINT16, and based on the PCI-to-PCI
Bridge Architecture Spec, Chapter 3.2, the actual MMIO aperture is
determined as in:

NonPrefetchMemoryBase  = (((MemoryBase  & 0xFFF0u) >> 4) << 20) | 0x00000
NonPrefetchMemoryLimit = (((MemoryLimit & 0xFFF0u) >> 4) << 20) | 0xFFFFF

In "OvmfPkg/PciHotPlugInitDxe", the
"mPadding.MmioPadding.AddrSpaceGranularity" field is currently initialized
to 64. According to the above, this is useless generality: a
non-prefetchable MMIO reservation may only be satisfied from 32-bit
address space. Update the field to 32.

In practice this change makes no difference, because PciBusDxe already
enforces the 32-bit limitation when it sees "non-prefetchable" from
(SpecificFlag==0). Quoting commit 8aba40b792 ("OvmfPkg: add
PciHotPlugInitDxe", 2016-06-30): "regardless of our request for 64-bit
MMIO reservation, it is downgraded to 32-bit".

(See the Platform Init Spec 1.6, Volume 5,
- Table 8. "ACPI 2.0 & 3.0 QWORD Address Space Descriptor Usage", and
- Table 11. "Memory Resource Flag (Resource Type = 0) Usage",
for an explanation of the "mPadding.MmioPadding" fields.)

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Fixes: 8aba40b792
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-10-03 16:07:33 +02:00
Laszlo Ersek 8aba40b792 OvmfPkg: add PciHotPlugInitDxe
After IncompatiblePciDeviceSupportDxe, this is another small driver /
protocol implementation that tweaks the behavior of the PCI bus driver in
edk2.

The protocol is specified in the Platform Init Spec v1.4a, Volume 5,
Chapter 12.6 "PCI Hot Plug PCI Initialization Protocol". This
implementation steers the PCI bus driver to reserve the following
resources ("padding") for each PCI bus, in addition to the BARs of the
devices on that PCI bus:
- 2MB of 64-bit non-prefetchable MMIO aperture,
- 512B of IO port space.

The goal is to reserve room for devices hot-plugged at runtime even if the
bridge receiving the device is empty at boot time.

The 2MB MMIO size is inspired by SeaBIOS. The 512B IO port size is
actually only 1/8th of the PCI spec mandated reservation, but the
specified size of 4096 has proved wasteful (given the limited size of our
IO port space -- see commit bba734ab4c). Especially on Q35, where every
PCIe root port and downstream port qualifies as a separate bridge (capable
of accepting a single device).

Test results for this patch:
- regardless of our request for 64-bit MMIO reservation, it is downgraded
  to 32-bit,
- although we request 512B alignment for the IO port space reservation,
  the next upstream bridge rounds it up to 4096B.

Cc: "Johnson, Brian J." <bjohnson@sgi.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Suggested-by: Andrew Fish <afish@apple.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
2016-07-13 08:39:50 +02:00