Commit Graph

23 Commits

Author SHA1 Message Date
Igor Druzhinin 0c40c9c925 OvmfPkg/XenSupport: turn off address decoding before BAR sizing
On Xen, hvmloader firmware leaves address decoding enabled for
enumerated PCI device before jumping into OVMF. OVMF seems to
expect it to be disabled and tries to size PCI BARs in several places
without disabling it which causes BAR64, for example, being
incorrectly placed by QEMU.

Fix it by disabling PCI address decoding explicitly before the
first attempt to size BARs on Xen.

Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
2019-04-30 18:42:35 +02:00
Igor Druzhinin d63610df60 OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64
In case BAR64 is placed below 4G choose the correct aperture.
This fixes a failed assertion down the code path.

Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
2019-04-30 18:41:57 +02:00
Igor Druzhinin 27e4d6ae25 OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture
This aperture doesn't exist in QEMU-XEN and hvmloader places BARs
in arbitrary order disregarding prefetchable bit. This makes
prefetchable and non-prefetchable BARs to follow each other that's
quite likely with PCI passthrough devices. In that case, the existing
code, that tries to work out aperture boundaries by reading hvmloader
BAR placement, will report a bogus prefetchable aperture which overlaps
with the regular one. It will eventually trigger an assertion in
DXE PCI initialization code.

Do the same thing as OVMF on QEMU-KVM and pass a non-existing aperture
there. It's not necessary to pass additional allocation flags as we set
ResourceAssigned flag on the root bridge which means they will be ignored.

Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
2019-04-30 18:41:57 +02:00
Michael D Kinney b26f0cf9ee OvmfPkg: Replace BSD License with BSD+Patent License
https://bugzilla.tianocore.org/show_bug.cgi?id=1373

Replace BSD 2-Clause License with BSD+Patent License.  This change is
based on the following emails:

  https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html
  https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html

RFCs with detailed process for the license change:

  V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html
  V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html
  V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-04-09 10:58:19 -07:00
chenc2 dbf9cc87cb OvmfPkg: Removing ipf which is no longer supported from edk2.
Removing rules for Ipf sources file:
* Remove the source file which path with "ipf" and also listed in
  [Sources.IPF] section of INF file.
* Remove the source file which listed in [Components.IPF] section
  of DSC file and not listed in any other [Components] section.
* Remove the embedded Ipf code for MDE_CPU_IPF.

Removing rules for Inf file:
* Remove IPF from VALID_ARCHITECTURES comments.
* Remove DXE_SAL_DRIVER from LIBRARY_CLASS in [Defines] section.
* Remove the INF which only listed in [Components.IPF] section in DSC.
* Remove statements from [BuildOptions] that provide IPF specific flags.
* Remove any IPF sepcific sections.

Removing rules for Dec file:
* Remove [Includes.IPF] section from Dec.

Removing rules for Dsc file:
* Remove IPF from SUPPORTED_ARCHITECTURES in [Defines] section of DSC.
* Remove any IPF specific sections.
* Remove statements from [BuildOptions] that provide IPF specific flags.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-06-29 16:19:47 +08:00
Heyi Guo e33305ea6c OvmfPkg/PciHostBridgeLib: clear PCI aperture vars for (re)init
Use ZeroMem() to initialize (or re-initialize) all fields in temporary
PCI_ROOT_BRIDGE_APERTURE variables to zero. This is not mandatory but
is helpful for future extension: when we add new fields to
PCI_ROOT_BRIDGE_APERTURE and the default value of these fields can
safely be zero, this code will not suffer from an additional
change.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Signed-off-by: Yi Li <phoenix.liyi@huawei.com>
Reviewed-by: Ni Ruiyu <ruiyu.ni@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-03-15 08:26:05 +00:00
Gary Lin 5a5025e485 OvmfPkg: Make more use of ARRAY_SIZE()
Convert the remaining pieces to make the code shorter and more readable.

Cc: Justen Jordan <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: tweak subject line]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2016-10-27 18:21:06 +02:00
Laszlo Ersek f982bb8d62 OvmfPkg/PciHostBridgeLib: silence IA32 VS2015x86 warnings
When compiling "OvmfPkg\Library\PciHostBridgeLib\XenSupport.c" for IA32,
the VS2015x86 compiler emits the following:

> XenSupport.c(41): error C2220: warning treated as error - no 'object'
>                                file generated
> XenSupport.c(41): warning C4244: 'function': conversion from 'UINT64' to
>                                  'UINTN', possible loss of data
> XenSupport.c(48): warning C4244: 'function': conversion from 'UINT64' to
>                                  'UINTN', possible loss of data
> XenSupport.c(49): warning C4244: 'function': conversion from 'UINT64' to
>                                  'UINTN', possible loss of data
> XenSupport.c(50): warning C4244: 'function': conversion from 'UINT64' to
>                                  'UINTN', possible loss of data
> XenSupport.c(222): warning C4244: 'function': conversion from 'UINT64'
>                                   to 'UINTN', possible loss of data
> XenSupport.c(241): warning C4244: 'function': conversion from 'UINT64'
>                                   to 'UINTN', possible loss of data

PciLib functions take UINTN addresses that were encoded with the
PCI_LIB_ADDRESS() macro. We carry addresses from the macro invocations to
the function calls in two UINT64 variables however. This loses no data,
but it alerts VS2015x86. Change the variable types to UINTN.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
2016-07-18 19:23:22 +02:00
Ruiyu Ni 49effaf26e OvmfPkg/PciHostBridgeLib: Scan for root bridges when running over Xen
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gary Lin <glin@suse.com>
2016-05-11 08:53:36 +08:00
Ruiyu Ni c0a2591b30 OvmfPkg/PciHostBridgeLib: Change InitRootBridge prototype
The patch re-factors the code without functionality impact.
Next patch will add code to support OVMF above Xen.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2016-05-11 08:53:36 +08:00
Ruiyu Ni c3933ccbba OvmfPkg/PciHostBridgeLib: Set correct Base/Limit for absent resource
In order to match the previous commit, Base must be strictly larger than
Limit if some type of aperture is not available on a PCI root bridge.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2016-05-11 08:53:36 +08:00
Laszlo Ersek 4f5eff8193 OvmfPkg: PciHostBridgeLib: install 64-bit PCI host aperture
On the normal boot path (which is when PciHostBridgeDxe runs), the PCDs
have been calculated; report the 64-bit PCI host aperture to
PciHostBridgeDxe.

In the Ia32 build, the PCD values (zeros) come directly from the DEC file,
and this patch makes no difference.

Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Thomas Lamprecht <t.lamprecht@proxmox.com>
Ref: https://github.com/tianocore/edk2/issues/59
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-23 17:47:31 +01:00
Laszlo Ersek 7daf2401d4 OvmfPkg: PciHostBridgeLib: permit access to the full extended config space
By now OVMF makes MdeModulePkg/Bus/Pci/PciHostBridgeDxe go through
MMCONFIG (when running on Q35). Enable the driver to address each B/D/F's
config space up to and including offset 0xFFF.

Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Micha³ Zegan <webczat_200@poczta.onet.pl>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Tested-by: Micha³ Zegan <webczat_200@poczta.onet.pl>
2016-03-10 21:28:37 +01:00
Laszlo Ersek 1f4e2299e7 OvmfPkg: PciHostBridgeLib: initialize RootBus->DevicePath
We copy the code from InitRootBridge()
[OvmfPkg/PciHostBridgeDxe/PciHostBridge.c], with a slight change: the
device path is allocated separately now.

This is the final field to initialize in PCI_ROOT_BRIDGE.

The type EFI_PCI_ROOT_BRIDGE_DEVICE_PATH is renamed to
OVMF_PCI_ROOT_BRIDGE_DEVICE_PATH. The original is a misnomer (it is not a
standard UEFI type) that dates back to PcAtChipsetPkg/PciHostBridgeDxe.
Simply removing the EFI_ suffix would result in
PCI_ROOT_BRIDGE_DEVICE_PATH, where PCI_ could incorrectly suggest a
relation with the PCI standards or the PCI-related generic edk2 code.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 18:18:43 +01:00
Laszlo Ersek cb81595b5d OvmfPkg: PciHostBridgeLib: set RootBus->NoExtendedConfigSpace
In "OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c", the
RootBridgeIoCheckParameter() function hard-codes the maximum offset for
the PCI config space as 0xFF (see the MAX_PCI_REG_ADDRESS macro), which
matches OVMF's 0xCF8 / 0xCFC config access method.

The "MdeModulePkg/Bus/Pci/PciHostBridgeDxe" driver abstracts away config
space access via the PciSegmentLib class, so it has to be informed
separately about the config space size.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 18:18:40 +01:00
Laszlo Ersek 390951c2b8 OvmfPkg: PciHostBridgeLib: set bus, IO and 32-bit MMIO windows in RootBus
The bus aperture is copied verbatim from InitRootBridge()
[OvmfPkg/PciHostBridgeDxe/PciHostBridge.c].

The IO and 32-bit MMIO apertures are matched to PlatformPei's settings.
PciHostBridgeLibDxe expects PciHostBridgeLib instances to advertize the
exact apertures.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 18:18:39 +01:00
Laszlo Ersek 0dcd1b1b2a OvmfPkg: PciHostBridgeLib: set RootBus->AllocationAttributes
InitRootBridge() in "OvmfPkg/PciHostBridgeDxe/PciHostBridge.c" passes the
EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM allocation attribute to
RootBridgeConstructor(); we should do the same here.

From "MdePkg/Include/Protocol/PciHostBridgeResourceAllocation.h":

/// If this bit is set, then the PCI Root Bridge does not support separate
/// windows for Non-prefetchable and Prefetchable memory. A PCI bus driver
/// needs to include requests for Prefetchable memory in the
/// Non-prefetchable memory pool.

Which implies that both the 32-bit and 64-bit prefetchable MMIO apertures
should be marked empty. (The CreateRootBridge() function actually enforces
this in "MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c".)

Furthermore, since OvmfPkg/PciHostBridgeDxe does *not* set the
EFI_PCI_HOST_BRIDGE_MEM64_DECODE allocation attribute:

/// If this bit is set, then the PCI Root Bridge supports 64 bit memory
/// windows.  If this bit is not set, the PCI bus driver needs to include
/// requests for 64 bit memory address in the corresponding 32 bit memory
/// pool.

we follow suit in the PciHostBridgeLib instance.

In turn, the 64-bit MMIO apertures (both prefetchable and
non-prefetchable) should be marked empty.
MdeModulePkg/Bus/Pci/PciHostBridgeDxe enforces this too.

(64-bit MMIO aperture support, based on yet more fw_cfg files, is a
planned future improvement.)

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 18:18:39 +01:00
Laszlo Ersek c789d61dcb OvmfPkg: PciHostBridgeLib: clear RootBus->DmaAbove4G
When this BOOLEAN member is FALSE, and the caller tries to set up a DMA
transfer between a PCI device and a host buffer not entirely under 4GB,
then "MdeModulePkg/Bus/Pci/PciHostBridgeDxe" sets up a bounce buffer under
4GB, in the implementation of EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Map().

Since that's exactly what RootBridgeIoMap() does in
"OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c", stick with it in this
conversion.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 18:18:39 +01:00
Laszlo Ersek a5ece62d79 OvmfPkg: PciHostBridgeLib: set supported and initial attributes in RootBus
These settings are copied from the RootBridgeConstructor() function, file
"OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c".

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 18:18:39 +01:00
Laszlo Ersek 65de2ef54f OvmfPkg: PciHostBridgeLib: set RootBus->Segment
This is the first of the patches that set the fields of PCI_ROOT_BRIDGE.
The structure is zero-filled as a precaution for later field additions.

Here we set the Segment member explicitly to zero (so that any later
customization can be easier).

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 18:18:39 +01:00
Laszlo Ersek dc4d64670a OvmfPkg: PciHostBridgeLib: implement PciHostBridgeFreeRootBridges()
This function has no counterpart in OvmfPkg/PciHostBridgeDxe/, but the
PciHostBridgeLib class requires it.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 18:18:39 +01:00
Laszlo Ersek 46e46eaf62 OvmfPkg: PciHostBridgeLib: convert main loop from PciHostBridgeDxe
In this patch we import the scan for extra root buses from the
InitializePciHostBridge() function, in file
"OvmfPkg/PciHostBridgeDxe/PciHostBridge.c".

For the time being, the InitRootBridge() and UninitRootBridge() functions
are just placeholders.

The PciHostBridgeGetRootBridges() API expects us to return the
PCI_ROOT_BRIDGE structures in a contiguous array, instead of a linked
list. Therefore the following bits have to be converted manually:

(1) The array is allocated in advance, in a single step.

(2) The calculation of the array size depends on an explicit
    multiplication, which we must check against overflow. Since more than
    255 extra root bridges make no sense anyway, we use (1 + 255) as the
    limit on the main plus all extra root bridges. This also ensures that
    the UINTN multiplication doesn't overflow.

(3) The PciHostBridgeDxe code decrements "ExtraRootBridgesLeft" to
    terminate the scanning early. Here we need track the increasing count
    of used array elements as well, so we employ "ExtraRootBridges" as a
    constant limit, and increment the new local variable "Initialized".

(4) The prototypes of InitRootBridge() and UninitRootBridge() reflect that
    the PCI_ROOT_BRIDGE structure is allocated by the caller; only
    in-place initialization is necessary.

Additionally, macros are employed for standard PCI quantities, from
"MdePkg/Include/IndustryStandard/Pci22.h":

- MAX_PCI_DEVICE_NUMBER (31) is replaced with PCI_MAX_DEVICE (same),
- the constant 255 is replaced with PCI_MAX_BUS,
- the (RootBridgeNumber < 256) condition is replaced with
  (RootBridgeNumber <= PCI_MAX_BUS).

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 18:18:35 +01:00
Laszlo Ersek d85861d718 OvmfPkg: clone PciHostBridgeLib from MdeModulePkg's Null instance
In this patch we clone "MdeModulePkg/Library/PciHostBridgeLibNull" for
customization under OvmfPkg. Differences relative to a verbatim copy:

- the Null suffix is dropped from file names,
- the UNI file is dropped, together with the corresponding MODULE_UNI_FILE
  reference in the INF file,
- the INF file receives a new FILE_GUID,
- the top comments in the files mention OVMF, not a null instance.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-03 18:18:35 +01:00