summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/IncompatiblePciDeviceSupportDxe
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/IncompatiblePciDeviceSupportDxe: ignore CSM presenceLaszlo Ersek2023-12-072-140/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The UEFI protocol database cannot contain gEfiLegacyBiosProtocolGuid any longer, after excluding LegacyBiosDxe from the OVMF platforms. Therefore, instruct PciBusDxe from IncompatiblePciDeviceSupportDxe to allocate 64-bit BARs above 4 GB regardless of a CSM. Regression test: in commit 855743f71774 ("OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM", 2016-05-25), where we introduced IncompatiblePciDeviceSupportDxe, we said, "By default, the PCI Bus driver considers an option ROM reason enough for allocating the 64-bit MMIO BARs in 32-bit address space". Therefore it suffices to verify the 64-bit BARs of a device for which QEMU provides an option ROM. The simplest case is the virtio-net-pci device. And indeed, with this patch applied, the log contains: > PciBus: Discovered PCI @ [04|00|00] [VID = 0x1AF4, DID = 0x1041] > BAR[1]: Type = Mem32; Alignment = 0xFFF; Length = 0x1000; Offset = 0x14 > BAR[4]: Type = PMem64; Alignment = 0x3FFF; Length = 0x4000; Offset = 0x20 This portion shows that Bus|Device|Function 04|00|00 is a (modern) virito-net-pci device [VID = 0x1AF4, DID = 0x1041]. > PciBus: Resource Map for Bridge [00|01|03] > Type = Mem32; Base = 0x81200000; Length = 0x200000; Alignment = 0x1FFFFF > Base = Padding; Length = 0x200000; Alignment = 0x1FFFFF > Base = 0x81200000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [04|00|00:14] > Type = Mem32; Base = 0x81A43000; Length = 0x1000; Alignment = 0xFFF > Type = PMem64; Base = 0x800200000; Length = 0x100000; Alignment = 0xFFFFF > Base = 0x800200000; Length = 0x4000; Alignment = 0x3FFF; Owner = PCI [04|00|00:20] This quote shows that 04|00|00 has a BAR at 0x8_0020_0000. (It also shows that the device is behind a bridge (PCIe root port) whose own BDF is 00|01|03.) > [Security] 3rd party image[7CEEB418] can be loaded after EndOfDxe: PciRoot(0x0)/Pci(0x1,0x3)/Pci(0x0,0x0)/Offset(0x10E00,0x273FF). > None of Tcg2Protocol/CcMeasurementProtocol is installed. > InstallProtocolInterface: [EfiLoadedImageProtocol] 7D2E5140 > Loading driver at 0x0007CA9F000 EntryPoint=0x0007CAA5447 1af41000.efi > InstallProtocolInterface: [EfiLoadedImageDevicePathProtocol] 7D5B2198 And this part finally shows that the iPXE option ROM for the device (1af41000.efi) was detected and is loaded. (Same PCIe root port, and PCIe root ports can only host a single device.) Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-14-lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Corvin Köhne <corvink@FreeBSD.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Format with Uncrustify 73.0.8Michael Kubacki2023-11-271-12/+12
| | | | | | | | | | | Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Corvin Köhne <corvink@freebsd.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Update code to be more C11 compliant by using __func__Rebecca Cran2023-04-101-1/+1
| | | | | | | | | | | | | __FUNCTION__ is a pre-standard extension that gcc and Visual C++ among others support, while __func__ was standardized in C99. Since it's more standard, replace __FUNCTION__ with __func__ throughout OvmfPkg. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
* OvmfPkg/IncompatiblePciDeviceSupportDxe: Ignore OptionRom in Sev guestLee, Chun-Yi2022-09-062-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | Reference: https://bugzilla.tianocore.org/show_bug.cgi?id=4031 This patch is similar to the c477b2783f patch for Td guest. Host VMM may inject OptionRom which is untrusted in Sev guest. So PCI OptionRom needs to be ignored if it is Sev guest. According to "Table 20. ACPI 2.0 & 3.0 QWORD Address Space Descriptor Usage" PI spec 1.7, type-specific flags can be set to 0 when Address Translation Offset == 6 to skip device option ROM. Without this patch, Sev guest may shows invalid MMIO opcode error as following: Invalid MMIO opcode (F6) ASSERT /home/abuild/rpmbuild/BUILD/edk2-edk2-stable202202/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c(1041): ((BOOLEAN)(0==1)) The OptionRom must be disabled both on Td and Sev guests, so we direct use CcProbe(). Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/IncompatiblePciDeviceSupportDxe: Ignore OptionRom in Td guestMin Xu2022-04-021-0/+46
| | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 Host VMM may inject OptionRom which is untrusted in Td guest. So PCI OptionRom needs to be ignored if it is Td guest. According to "Table 20. ACPI 2.0 & 3.0 QWORD Address Space Descriptor Usage" PI spec 1.7, type-specific flags can be set to 0 when Address Translation Offset == 6 to skip device option ROM. Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/IncompatiblePciDeviceSupportDxe: Refine the configurationMin Xu2022-04-021-31/+33
| | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 MMIO64_PREFERENCE is a fixed length data structure which contains one AddressSpaceDesc and one EndDesc. This patch removes MMIO64_PREFERENCE and create AddressSpaceDesc and EndDesc respectively. This change gives the chance to add more AddressSpaceDesc when CheckDevice is called. Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Apply uncrustify changesMichael Kubacki2021-12-071-36/+53
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the OvmfPkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Andrew Fish <afish@apple.com>
* OvmfPkg/IncompatiblePciDeviceSupportDxe: remove PcdPciDisableBusEnumerationLaszlo Ersek2021-06-042-9/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | At this point, the IncompatiblePciDeviceSupportDxe driver is included in the following platforms in edk2: OvmfPkg/AmdSev/AmdSevX64.dsc OvmfPkg/OvmfPkgIa32.dsc OvmfPkg/OvmfPkgIa32X64.dsc OvmfPkg/OvmfPkgX64.dsc All those platforms inherit FALSE for "PcdPciDisableBusEnumeration" from "MdeModulePkg.dec". This makes the PcdGetBool() call in the entry point of the driver superfluous; remove it. Clean up now unused dependencies in the INF file as well. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-28-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg: replace old EFI_D_ debug levels with new DEBUG_ onesRebecca Cran2020-04-301-1/+1
| | | | | | | | | | | | | Generated mechanically with: find OvmfPkg -type f -exec sed -i -e 's/EFI_D_/DEBUG_/g' {} \; Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Philippe Mathieu-Daude <philmd@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200429215327.606467-1-rebecca@bsdio.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/IncompatiblePciDeviceSupportDxe: Drop framework pkg dependencyHao A Wu2019-06-171-1/+0
| | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843 This commit will drop the driver's dependency on the IntelFrameworkPkg: gEfiLegacyBiosProtocolGuid Such dependency has already been addressed by the duplication of the above definition from IntelFrameworkPkg into the OvmfPkg. Cc: Ray Ni <ray.ni@intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-092-14/+2
| | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/IncompatiblePci: Do not use deprecated macrosRuiyu Ni2017-02-101-6/+7
| | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSMLaszlo Ersek2016-05-252-0/+403
According to edk2 commit "MdeModulePkg/PciBus: do not improperly degrade resource" and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the Platform Init 1.4a specification, a platform can provide such a protocol in order to influence the PCI resource allocation performed by the PCI Bus driver. In particular it is possible instruct the PCI Bus driver, with a "wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit address space, regardless of whether the device features an option ROM. (By default, the PCI Bus driver considers an option ROM reason enough for allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS binary from a combined option ROM could be dispatched, and fail to access MMIO BARs in 64-bit address space.) In platform code we can ascertain whether a CSM is present or not. If not, then legacy BIOS binaries in option ROMs can't be dispatched, hence the BAR degradation is detrimental, and we should prevent it. This is expected to conserve the 32-bit address space for 32-bit MMIO BARs. The driver added in this patch could be simplified based on the following facts: - In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence the driver will exit immediately. Therefore the driver could be omitted from the Ia32 build. - In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE was defined (because in that case the degradation would be justified). On the other hand, if CSM_ENABLE was undefined, then the driver could be included, and it could provide the hint unconditionally (without looking for the Legacy BIOS protocol). These short-cuts are not taken because they would increase the differences between the OVMF DSC/FDF files. If we can manage without extreme complexity, we should use dynamic logic (vs. build time configuration), plus keep conditional compilation to a minimum. 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: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-21 13:49:28 +0000