summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: remove PciHostBridgeDxe forkLaszlo Ersek2016-04-077-5331/+0
| | | | | | | | | This driver is now unused. Cc: Jordan Justen <jordan.l.justen@intel.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>
* OvmfPkg: remove USE_OLD_PCI_HOST build optionLaszlo Ersek2016-04-076-69/+0
| | | | | | | | | | | | | | | | | | It's been a month since the following commits appeared in the repo: 4014885ffdfa8 OvmfPkg: switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe c47ed6fcb5e60 OvmfPkg: match PCI config access to machine type (if not USE_OLD_PCI_HOST) in which we introduced the USE_OLD_PCI_HOST fallback, and made other work depend on it. I have not heard of any problems (primarily from the vfio-users group that uses Gerd's daily / hourly OVMF builds), so it's time to drop the fallback. Cc: Jordan Justen <jordan.l.justen@intel.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>
* OvmfPkg: Convert to using FatPkg in the EDK II treeJordan Justen2016-04-076-4/+7
| | | | | | | | | | | | | Now that FatPkg is open source (and therefore can be included in the EDK II tree) we build and use it directly. Build tested with GCC 5.3 on IA32 and X64. Boot tested to UEFI Shell on IA32 and UEFI Linux on X64. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Retire AcpiS3SaveDxeStar Zeng2016-04-078-631/+3
| | | | | | | | | | | | | The same functional code has been in S3SaveStateDxe, OVMF AcpiS3SaveDxe can be retired now. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Install LockBox protocol in constructor of LockBoxDxeLibStar Zeng2016-04-074-20/+36
| | | | | | | | | | | | | | | | | | | | Currently, the LockBox protocol is installed in entrypoint of OVMF AcpiS3SaveDxe. We can let the first driver run with LockBoxDxeLib linked to have its library constructor to install LockBox protocol on the ImageHandle. As other drivers may have gEfiLockBoxProtocolGuid dependency, the first driver should run before them. The later patches to retire AcpiS3SaveDxe for OVMF depends on this patch. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Set PcdAcpiS3Enable according to QemuFwCfgS3Enabled()Star Zeng2016-04-075-2/+10
| | | | | | | | | | | | Also need to declare PcdAcpiS3Enable as DynamicDefault in *.dsc. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: disable PcdHiiOsRuntimeSupportLaszlo Ersek2016-04-063-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Edk2 commit 8a45f80edad4 ("MdeModulePkg: Make HII configuration settings available to OS runtime") implements the optional UEFI feature described in "31.2.11.1 OS Runtime Utilization" in UEFI v2.6. While this feature might show benefits down the road even in QEMU virtual machines, at the moment it only presents drawbacks: - it increases the EfiRuntimeServicesData footprint, - it triggers HII compatibility problems between edk2 and external drivers unconditionally, even if the end-user is not interested in HII and/or in configuring said drivers (see <https://www.redhat.com/archives/vfio-users/2016-March/msg00153.html> and <http://thread.gmane.org/gmane.comp.bios.edk2.devel/9894> for an example). While the feature was being introduced, popular demand for a controlling Feature PCD rose (see <http://thread.gmane.org/gmane.comp.bios.edk2.devel/7626>), which is why we can set it now to FALSE. Cc: Jordan Justen <jordan.l.justen@intel.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>
* OvmfPkg: remove PcdMaxHardwareErrorVariableSize from the DSC filesLaszlo Ersek2016-04-063-3/+0
| | | | | | | | | | | | | | | | | | | | | | PcdMaxHardwareErrorVariableSize sets the size limit for individual Hardware Error Record Variables (see "7.2.3 Hardware Error Record Persistence" and "Appendix P, Hardware Error Record Persistence Usage" in the UEFI-2.6 spec). Since Hardware Error Record Persistence is an optional firmware feature, according to the spec, and OVMF does not enable it -- it inherits PcdHwErrStorageSize and PcdHardwareErrorRecordLevel with zero values --, the PcdMaxHardwareErrorVariableSize setting in our DSC files has no effect. Remove it in order to eliminate future confusion. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Star Zeng <star.zeng@intel.com> Suggested-by: Star Zeng <star.zeng@intel.com> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/9743/focus=9780 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: include Virtio10DxeLaszlo Ersek2016-04-066-0/+6
| | | | | | | | Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Virtio10Dxe: non-transitional driver for virtio-1.0 PCI devicesLaszlo Ersek2016-04-063-0/+1157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This driver implements the VIRTIO_DEVICE_PROTOCOL for non-transitional PCI devices, based on the virtio-1.0 specification (csprd05). Non-transitional means that it only binds QEMU's virtio-xxx-pci devices that receive the ",disable-legacy=on,disable-modern=off" properties on the QEMU command line. These devices have distinct PCI Device IDs from those that are bound by VirtioPciDeviceDxe. The central abstraction of this driver is the VIRTIO_1_0_CONFIG type. It is practically a "fat pointer" to a register block. The pointed-to register block - may or may not exist (the latter being mostly useful for virtio-1.0 devices that have no device-specific registers), - lives in one of the device's BARs, - lives in an IO or MMIO BAR, - lives at an offset relative to the BAR start, - has its size also maintained. Such VIRTIO_1_0_CONFIG "fat pointers" (i.e., the locations of the register blocks) are parsed from vendor capabilities that reside in the device's standard PCI capabilities list (in PCI config space). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: VirtioNetDxe: adapt virtio-net packet header size to virtio-1.0Laszlo Ersek2016-04-062-8/+30
| | | | | | | | | | | | | | | | | | | | | | In virtio-0.9.5, the size of the virtio-net packet header depends on whether the VIRTIO_NET_F_MRG_RXBUF feature is negotiated -- the "num_buffers" field is only appended to the header if the feature is negotiated. Since we never negotiate this feature, VirtioNetDxe never allocates room for the "num_buffers" field. With virtio-1.0, the "num_buffers" field is always there (although it doesn't carry useful information without VIRTIO_NET_F_MRG_RXBUF). Adapt the buffers that depend on the virtio-net header size (otherwise we have skewed / truncated packets). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: VirtioScsiDxe: adapt feature negotiation to virtio-1.0Laszlo Ersek2016-04-061-7/+20
| | | | | | | | | | | | | | | | | | Relative to virtio-0.9.5, virtio-1.0 reverses the order of queue discovery and feature negotiation. In virtio-1.0, feature negotiation has to complete first, and the device can also reject a self-inconsistent feature request through the new VSTAT_FEATURES_OK status bit. (For example if the driver requests a higher level feature but clears a prerequisite feature.) Furthermore, we retain the VIRTIO_F_VERSION_1 feature bit if the VIRTIO_DEVICE_PROTOCOL provider has high enough revision. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: VirtioRngDxe: adapt feature negotiation to virtio-1.0Laszlo Ersek2016-04-061-7/+20
| | | | | | | | | | | | | | | | | | Relative to virtio-0.9.5, virtio-1.0 reverses the order of queue discovery and feature negotiation. In virtio-1.0, feature negotiation has to complete first, and the device can also reject a self-inconsistent feature request through the new VSTAT_FEATURES_OK status bit. (For example if the driver requests a higher level feature but clears a prerequisite feature.) Furthermore, we retain the VIRTIO_F_VERSION_1 feature bit if the VIRTIO_DEVICE_PROTOCOL provider has high enough revision. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: VirtioNetDxe: adapt feature negotiation to virtio-1.0Laszlo Ersek2016-04-061-4/+19
| | | | | | | | | | | | | | | | | | Relative to virtio-0.9.5, virtio-1.0 reverses the order of queue discovery and feature negotiation. In virtio-1.0, feature negotiation has to complete first, and the device can also reject a self-inconsistent feature request through the new VSTAT_FEATURES_OK status bit. (For example if the driver requests a higher level feature but clears a prerequisite feature.) Furthermore, we retain the VIRTIO_F_VERSION_1 feature bit if the VIRTIO_DEVICE_PROTOCOL provider has high enough revision. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: VirtioBlkDxe: adapt feature negotiation to virtio-1.0Laszlo Ersek2016-04-061-5/+20
| | | | | | | | | | | | | | | | | | Relative to virtio-0.9.5, virtio-1.0 reverses the order of queue discovery and feature negotiation. In virtio-1.0, feature negotiation has to complete first, and the device can also reject a self-inconsistent feature request through the new VSTAT_FEATURES_OK status bit. (For example if the driver requests a higher level feature but clears a prerequisite feature.) Furthermore, we retain the VIRTIO_F_VERSION_1 feature bit if the VIRTIO_DEVICE_PROTOCOL provider has high enough revision. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: VirtioLib: add Virtio10WriteFeatures() functionLaszlo Ersek2016-04-062-0/+121
| | | | | | | | | | | | | | | | In VirtIo 1.0, a device can reject a self-inconsistent feature bitmap through the new VSTAT_FEATURES_OK status bit. (For example if the driver requests a higher level feature but clears a prerequisite feature.) This function is a small wrapper around VIRTIO_DEVICE_PROTOCOL.SetGuestFeatures() that also verifies if the VirtIo 1.0 device accepts the feature bitmap. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: IndustryStandard: add definitions from the VirtIo 1.0 specLaszlo Ersek2016-04-064-2/+115
| | | | | | | | | | | | | | | | | | | | | | These header files are intentionally minimal, and intentionally kept apart from the VirtIo 0.9.5 headers. The header inclusion chains end up like this (the Virtio10*.h header files in the middle are new): Virtio.h -> Virtio10.h -> Virtio095.h ^ ^ | | VirtioNet.h -> Virtio10Net.h -> Virtio095Net.h Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: IndustryStandard: factor out Virtio095Net.hLaszlo Ersek2016-04-062-78/+100
| | | | | | | | | | | | | | | | | | | | | | | In the upcoming virtio-1.0 series, we'll introduce "Virtio10Net.h". However, the "VirtioNet.h" header file should continue to expose the Virtio Network Device specific type and macro definitions for all virtio versions that OvmfPkg supports. Therefore extract "Virtio095Net.h" like this: VirtioNet.h -> Virtio095Net.h so that in the upcoming patches, we can insert "Virtio10Net.h" in the middle of the inclusion chain. This follows the example of "Acpi.h" and "Pci.h" under "MdePkg/Include/IndustryStandard". Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Suggested-by: Jordan Justen <jordan.l.justen@intel.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>
* OvmfPkg: IndustryStandard: factor out Virtio095.hLaszlo Ersek2016-04-062-155/+179
| | | | | | | | | | | | | | | | | | | | | | In the upcoming virtio-1.0 series, we'll introduce "Virtio10.h". However, the "Virtio.h" header file should continue to expose the generic type and macro definitions for all virtio versions that OvmfPkg supports. Therefore extract "Virtio095.h" like this: Virtio.h -> Virtio095.h so that in the upcoming patches, we can insert "Virtio10.h" in the middle of the inclusion chain. This follows the example of "Acpi.h" and "Pci.h" under "MdePkg/Include/IndustryStandard". Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Suggested-by: Jordan Justen <jordan.l.justen@intel.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>
* OvmfPkg: VirtioRngDxe: clear all feature bits more explicitlyLaszlo Ersek2016-04-061-1/+2
| | | | | | | | | | | | | | This too is in preparation for the following patches. After this patch, all four drivers manage their feature bits with explicit masking. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: VirtioBlkDxe: don't clear non-negotiable feature bitsLaszlo Ersek2016-04-061-5/+4
| | | | | | | | | | | | | VirtioBlkDxe only recognizes virtio-block feature bits that the device offers non-negotiably. Nonetheless, in preparation for the following patches, don't try to clear them even for simplicity. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: VIRTIO_DEVICE_PROTOCOL: pass VRING object to SetQueueAddress()Laszlo Ersek2016-04-069-24/+21
| | | | | | | | | | | | | | | | In virtio-1.0, it is not enough to pass the base address of the virtio queue to the hypervisor (as a frame number); instead it will want the addresses of the descriptor table, the available ring, and the used ring separately. Pass the VRING object to the SetQueueAddress() member function; this will enable a virtio-1.0 implementation. Convert the current producers and consumers to this prototype. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: VIRTIO_DEVICE_PROTOCOL: remove GetQueueAddress() memberLaszlo Ersek2016-04-067-77/+0
| | | | | | | | | | | | | This function was never consumed by drivers, and the current prototype is unsupportable with virtio-1.0. Remove the function from the protocol definition, and drop the current (unused) implementations. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: VIRTIO_DEVICE_PROTOCOL: widen the Features bitmap to 64 bitsLaszlo Ersek2016-04-0610-20/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The virtio-1.0 spec widens the Features bitmap to 64 bits. Modify the declarations of the GetDeviceFeatures() and SetGuestFeatures() protocol member functions accordingly. Normally, a protocol cannot be changed in incompatible ways if the GUID stays the same; however, we've always been extremely clear that VIRTIO_DEVICE_PROTOCOL is internal to edk2. See for example the top of "OvmfPkg/Include/Protocol/VirtioDevice.h". In this patch, all producers and consumers of the GetDeviceFeatures() and SetGuestFeatures() protocol members are updated. The drivers that currently produce these members are "legacy" drivers (in virtio-1.0 terminology), and they cannot (and will not) handle feature bits above BIT31. Therefore their conversion is only for compatibility with the modified protocol interface. The consumers will be responsible for checking the VIRTIO_DEVICE_PROTOCOL.Revision field, and for not passing feature bits that these backends cannot handle. The VirtioMmioGetDeviceFeatures() implementation stores the result of an MmioRead32() call with normal assignment, so it needs no change beyond adapting its prototype. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Add RAM disk supportAlcantara, Paulo2016-04-016-6/+6
| | | | | | | | | | | | | | | Currently booting off of a RAM disk is not supported by IntelFrameWorkModulePkg BDS, however on systems without writable disks, the RAM disk can be made useful when loading raw HDD images into it -- specially the ones with a FAT32 partition on which files can be natively accessed by system firmware. This patch adds RamDiskDxe driver by default in OVMF platform. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paulo Alcantara <paulo.alc.cavalcanti@hp.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Increase the maximum size for Authenticated variablesJames Bottomley2016-03-253-0/+3
| | | | | | | | | | | | | | | | | During real world testing I was getting an error with too many entries in db: On my Secure boot laptop, I currently have seven certificates: two Microsoft ones, Three Kernel ones from various distributions, my own Secure Key and a temporary test key. That gives a total EFI Signature List size of 8317 which is over the 0x2000 maximum. Fix this by setting the PcdMaxAuthVariableSize to 0x2800 (10K) which isn't much of an increase but allows for 9-10 certificates. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* OvmfPkg: PciHostBridgeLib: install 64-bit PCI host apertureLaszlo Ersek2016-03-232-0/+9
| | | | | | | | | | | | | | | | | | 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>
* OvmfPkg: PlatformPei: determine the 64-bit PCI host aperture for X64 DXELaszlo Ersek2016-03-235-0/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main observation about the 64-bit PCI host aperture is that it is the highest part of the useful address space. It impacts the top of the GCD memory space map, and, consequently, our maximum address width calculation for the CPU HOB too. Thus, modify the GetFirstNonAddress() function to consider the following areas above the high RAM, while calculating the first non-address (i.e., the highest inclusive address, plus one): - the memory hotplug area (optional, the size comes from QEMU), - the 64-bit PCI host aperture (we set a default size). While computing the first non-address, capture the base and the size of the 64-bit PCI host aperture at once in PCDs, since they are natural parts of the calculation. (Similarly to how PcdPciMmio32* are not rewritten on the S3 resume path (see the InitializePlatform() -> MemMapInitialization() condition), nor are PcdPciMmio64*. Only the core PciHostBridgeDxe driver consumes them, through our PciHostBridgeLib instance.) Set 32GB as the default size for the aperture. Issue#59 mentions the NVIDIA Tesla K80 as an assignable device. According to nvidia.com, these cards may have 24GB of memory (probably 16GB + 8GB BARs). As a strictly experimental feature, the user can specify the size of the aperture (in MB) as well, with the QEMU option -fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536 The "X-" prefix follows the QEMU tradition (spelled "x-" there), meaning that the property is experimental, unstable, and might go away any time. Gerd has proposed heuristics for sizing the aperture automatically (based on 1GB page support and PCPU address width), but such should be delayed to a later patch (which may very well back out "X-PciMmio64Mb" then). For "everyday" guests, the 32GB default for the aperture size shouldn't impact the PEI memory demand (the size of the page tables that the DXE IPL PEIM builds). Namely, we've never reported narrower than 36-bit addresses; the DXE IPL PEIM has always built page tables for 64GB at least. For the aperture to bump the address width above 36 bits, either the guest must have quite a bit of memory itself (in which case the additional PEI memory demand shouldn't matter), or the user must specify a large aperture manually with "X-PciMmio64Mb" (and then he or she is also responsible for giving enough RAM to the VM, to satisfy the PEI memory demand). 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 Ref: http://www.nvidia.com/object/tesla-servers.html Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: PlatformPei: factor out GetFirstNonAddress()Laszlo Ersek2016-03-231-1/+17
| | | | | | | | | | | | | | | Factor out the expression that is currently the basis of the address width calculation into a standalone function. In the next patches we'll raise the return value under certain circumstances. 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>
* OvmfPkg: AcpiPlatformDxe: enable PCI IO and MMIO while fetching QEMU tablesLaszlo Ersek2016-03-235-0/+212
| | | | | | | | | | | | | | | | | | | | | Now that the previous patches ensure that we can access all PCI devices in AcpiPlatformDxe, we can enable IO and MMIO decoding for all of them while we contact QEMU for the ACPI tables. See more details in the patch titled: OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid In particular, this patch will prevent the bug when the 64-bit MMIO aperture is completely missing from QEMU's _CRS, and consequently Linux rejects 64-bit BARs with the error message pci 0000:00:03.0: can't claim BAR 4 [mem 0x800000000-0x8007fffff 64bit pref]: no compatible bridge window Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.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>
* OvmfPkg: AcpiPlatformDxe: when PCI is enabled, wait for Platform BDS's cueLaszlo Ersek2016-03-233-36/+18
| | | | | | | | | | | | | | | | | | | | | | | | This patch doesn't change the behavior of AcpiPlatformDxe when PcdPciDisableBusEnumeration is TRUE -- that is, when the driver runs on Xen (OvmfPkg and ArmVirtPkg both), or when the driver runs on QEMU as part of ArmVirtPkg but no PCI host bridge was found by VirtFdtDxe. In these cases the driver continues to install the ACPI tables immediately. However, when PcdPciDisableBusEnumeration is FALSE (i.e., when the driver runs on QEMU as part of OVMF, or as part of ArmVirtPkg and VirtFdtDxe finds a PCI host bridge), we now delay the ACPI table download from QEMU. We wait until the Platform BDS tells us that root bridges have been connected, and PciIo instances are available. The explanation is in the patch titled OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.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>
* OvmfPkg: PlatformBdsLib: signal gRootBridgesConnectedEventGroupGuidLaszlo Ersek2016-03-232-0/+7
| | | | | | | | | | | | | | The explanation is in the patch titled OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid At this point, this signal doesn't do anything yet. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.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>
* OvmfPkg: introduce gRootBridgesConnectedEventGroupGuidLaszlo Ersek2016-03-232-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QEMU's ACPI table generator can only create meaningful _CRS objects -- apertures -- for the root buses if all of the PCI devices behind those buses are actively decoding their IO and MMIO resources, at the time of the firmware fetching the "etc/table-loader" fw_cfg file. This is not a QEMU error; QEMU follows the definition of BARs (which are meaningless when decoding is disabled). Currently we hook up AcpiPlatformDxe to the PCI Bus driver's gEfiPciEnumerationCompleteProtocolGuid cue. Unfortunately, when the PCI Bus driver installs this protocol, it's *still* not the right time for fetching "etc/table-loader": although resources have been allocated and BARs have been programmed with them, the PCI Bus driver has also cleared IO and MMIO decoding in the command registers of the devices. Furthermore, we couldn't reenable IO and MMIO decoding temporarily in our gEfiPciEnumerationCompleteProtocolGuid callback even if we wanted to, because at that time the PCI Bus driver has not produced PciIo instances yet. Our Platform BDSes are responsible for connecting the root bridges, hence they know exactly when the PciIo instances become available -- not when PCI enumeration completes (signaled by the above protocol), but when the ConnectController() calls return. This is when our Platform BDSes should explicitly cue in AcpiPlatformDxe. Then AcpiPlatformDxe can temporarily enable IO and MMIO decoding for all devices, while it contacts QEMU for the ACPI payload. This patch introduces the event group GUID that we'll use for unleashing AcpiPlatformDxe from our Platform BDSes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.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>
* OvmfPkg: OvmfPkg.dec: add horizontal whitespace under Guids and ProtocolsLaszlo Ersek2016-03-231-9/+9
| | | | | | | | | We'll need more room in the next patch. No functional changes. Cc: Jordan Justen <jordan.l.justen@intel.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>
* OvmfPkg/PlatformBdsLib: rebase to EfiEventGroupSignalLaszlo Ersek2016-03-231-29/+1
| | | | | | | | Cc: Jordan Justen <jordan.l.justen@intel.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> Reviewed-by: Liming Gao <liming.gao@intel.com>
* OvmfPkg/PlatformPei: suppress wrong VS2008 warning (use of uninited local)Laszlo Ersek2016-03-191-0/+1
| | | | | | | | | | | | | | | | | VS2008 seems to think that the "PciExBarBase" variable (introduced in commit 7b8fe63561b4) can be evaluated for the AddReservedMemoryBaseSizeHob() function call with its value being uninitialized / indeterminate. This is not the case (see "mHostBridgeDevId"); suppress the warning. Reported-by: David Woodhouse <dwmw2@infradead.org> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/8871/focus=9431 Cc: David Woodhouse <dwmw2@infradead.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: David Woodhouse <David.Woodhouse@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/LegacyRegion: Support legacy region manipulation of Q35Ruiyu Ni2016-03-152-39/+87
| | | | | | | | | | | | | | | | | | | Current implementation only supports legacy region of 440 chip. When QEMU is launched in Q35 mode using CSM enabled OVMF image, LegacyBios driver fails to start due to the legacy region [0xC0000, 0xFFFFF] cannot be written. v2: * just updates the comments. v3: * uses PcdOvmfHostBridgePciDevId as Jordan suggested. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Justen Jordan <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: PciHostBridgeLib: permit access to the full extended config spaceLaszlo Ersek2016-03-102-1/+4
| | | | | | | | | | | | | | | | | 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>
* OvmfPkg: match PCI config access to machine type (if not USE_OLD_PCI_HOST)Laszlo Ersek2016-03-103-0/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If USE_OLD_PCI_HOST is FALSE, then we switch all executable module types supported by DxePciLibI440FxQ35 to the following library instance stack: BasePciSegmentLibPci [class: PciSegmentLib] DxePciLibI440FxQ35 [class: PciLib] BasePciCf8Lib [class: PciCf8Lib] BasePciExpressLib [class: PciExpressLib] Every module will select 0xCF8 vs. ECAM based on the OVMF platform type (i440fx or Q35). Notably, MdeModulePkg/Bus/Pci/PciHostBridgeDxe is among the affected drivers. The BasePciExpressLib instance is where the PcdPciExpressBaseAddress PCD fills its original role. 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>
* OvmfPkg: add DxePciLibI440FxQ35Laszlo Ersek2016-03-102-0/+1276
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This library is a trivial unification of the following two PciLib instances (and the result is easily diffable against each): - MdePkg/Library/BasePciLibCf8 - MdePkg/Library/BasePciLibPciExpress The PCI config access method is determined in the constructor function, from the dynamic PCD "PcdOvmfHostBridgePciDevId" that is set by PlatformPei. The library instance is usable in DXE phase or later modules: the PciLib instances being unified have no firmware phase / client module type restrictions, and here the only PCD access is made in the constructor function. That is, even before a given client executable's entry point is invoked. The library instance depends on PlatformPei both for setting the PCD mentioned above, and also for enabling MMCONFIG on Q35. PEI and earlier phase modules are not expected to need extended config access even on Q35. 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>
* OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35Laszlo Ersek2016-03-105-4/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The comments in the code should speak for themselves; here we note only two facts: - The PCI config space writes (to the PCIEXBAR register) are performed using the 0xCF8 / 0xCFC IO ports, by virtue of PciLib being resolved to BasePciLibCf8. (This library resolution will permanently remain in place for the PEI phase.) - Since PCIEXBAR counts as a chipset register, it is the responsibility of the firmware to reprogram it at S3 resume. Therefore PciExBarInitialization() is called regardless of the boot path. (Marcel recently posted patches for SeaBIOS that implement this.) This patch suffices to enable PCIEXBAR (and the dependent ACPI table generation in QEMU), for the sake of "PCIeHotplug" in the Linux guest: ACPI: MCFG 0x000000007E17F000 00003C (v01 BOCHS BXPCMCFG 00000001 BXPC 00000001) PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000) PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820 acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability] In the following patches, we'll equip the core PCI host bridge / root bridge driver and the rest of DXE as well to utilize ECAM on Q35. 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> Ref: https://github.com/tianocore/edk2/issues/32 Ref: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/10548 Suggested-by: Marcel Apfelbaum <marcel@redhat.com> Reported-by: Michał Zegan <webczat_200@poczta.onet.pl> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Michał Zegan <webczat_200@poczta.onet.pl> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: PlatformPei: lower the 32-bit PCI MMIO base to 2GB on Q35Laszlo Ersek2016-03-101-4/+3
| | | | | | | | | | | | | | | | | | | | | Gerd has advised us that long term support Q35 machine types have no low RAM above 2GB, hence we should utilize the [2GB, 3GB) gap -- that we currently leave unused -- for MMIO. (Plus, later in this series, for the PCIEXBAR too.) 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> Ref: https://github.com/tianocore/edk2/issues/32 Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/8707/focus=8817 Suggested-by: Gerd Hoffmann <kraxel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Michał Zegan <webczat_200@poczta.onet.pl> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: IndustryStandard/Q35MchIch9.h: add PCIEXBAR macrosLaszlo Ersek2016-03-101-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | Section 5.1.16 ("PCIEXBAR -- PCI Express Register Range Base Address") in Intel document #316966-002 (already referenced near the top of this header file) describes the Q35 DRAM Controller register that configures the memory-mapped PCI config space (also known as MMCONFIG, and ECAM / Enhanced Configuration Access Method). In this patch we add the macros we'll need later. We'll only support the 256 MB memory-mapped config space -- enough for buses [0, 255]. 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> Ref: https://github.com/tianocore/edk2/issues/32 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@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>
* OvmfPkg: Enable Network2 Shell Commands for IPv6Gary Lin2016-03-083-0/+9
| | | | | | | | | | Enable the network2 commands when NETWORK_IP6_ENABLE is TRUE, so we would have Ping6 and Ifconfig6. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Ching-Pang Lin <glin@suse.com> [lersek@redhat.com: added the word "Shell" to the subject] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg PciHostBridgeDxe: Convert X64/IoFifo.asm to NASMJordan Justen2016-03-083-139/+15
| | | | | | | | | | The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert X64/IoFifo.asm to X64/IoFifo.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg PciHostBridgeDxe: Convert Ia32/IoFifo.asm to NASMJordan Justen2016-03-083-153/+14
| | | | | | | | | | The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert Ia32/IoFifo.asm to Ia32/IoFifo.nasm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxeLaszlo Ersek2016-03-036-0/+36
| | | | | | | | | | | | | | | | | | | | | The old driver is retained for now; it remains available with "-D USE_OLD_PCI_HOST". This is because I'd like to involve end users and downstreams in testing the new drier, but also allow them to switch back to the old driver at the first sight of trouble, while we debug the new driver in parallel. In a few weeks the ifdeffery and the "OvmfPkg/PciHostBridgeDxe/" driver should be removed. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Gerd Hoffmann <kraxel@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>
* OvmfPkg: resolve PciSegmentLibLaszlo Ersek2016-03-033-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the next patch we'll build "MdeModulePkg/Bus/Pci/PciHostBridgeDxe". That driver depends on the PciSegmentLib class. Edk2 offers four instances: (1) MdePkg/Library/UefiPciSegmentLibPciRootBridgeIo/ Inappropriate here because it consumes EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL, but "MdeModulePkg/Bus/Pci/PciHostBridgeDxe" needs the library class for producing that protocol. (2) MdePkg/Library/PeiPciSegmentLibPciCfg2/ Restricted to PEIM, SEC, and PEI_CORE client modules. (3) MdePkg/Library/DxePciSegmentLibEsal/ "uses ESAL services to perform PCI Configuration cycles" (4) MdePkg/Library/BasePciSegmentLibPci/ A simple BASE library instance that sits on top of PciLib. This is our choice. We can resolve PciSegmentLib to this instance for all module types. 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>
* OvmfPkg: PciHostBridgeLib: initialize RootBus->DevicePathLaszlo Ersek2016-03-032-1/+53
| | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg: PciHostBridgeLib: set RootBus->NoExtendedConfigSpaceLaszlo Ersek2016-03-031-0/+2
| | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-01 04:49:20 +0000