summaryrefslogtreecommitdiff
path: root/OvmfPkg/Bhyve/BhyveRfbDxe
AgeCommit message (Collapse)AuthorFilesLines
2023-12-07OvmfPkg: exclude the CSM-based VideoDxe driverLaszlo Ersek1-2/+0
The CSM-based VideoDxe driver is a special UEFI_DRIVER module that both follows and doesn't follow the UEFI driver model. Namely, in the Supported and Start members of its Driver Binding Protocol instance, it consumes the Legacy Bios Protocol directly from the UEFI protocol database, as opposed to (only) opening protocols on the handle that it is supposed to bind. Furthermore, the driver "marks" its own image handle with the NULL-interface "Legacy Bios" (pseudo-protocol) GUID, in order to "inform back" the provider of the Legacy Bios Protocol, i.e., LegacyBiosDxe, that VideoDxe is a "BIOS Thunk Driver" in the system. Quoting "OvmfPkg/Csm/Include/Guid/LegacyBios.h", such a driver follows the UEFI Driver Model, but still uses the Int86() or FarCall() services of the Legacy Bios Protocol as the basis for the UEFI protocol it produces. In a sense, there is a circular dependency between VideoDxe and LegacyBiosDxe; each knows about the other. However, VideoDxe is a UEFI_DRIVER, while LegacyBiosDxe is a platform DXE_DRIVER with a very long DEPEX. Therefore, for keeping dependencies conceptually intact, first exclude VideoDxe from the OVMF platforms. Always include the hypervisor-specific real UEFI video driver. --*-- Note that the pathname "IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf" in the bhyve platform DSC and FDF files is bogus anyway. Cc: Anthony Perard <anthony.perard@citrix.com> 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> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4588 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20231110235820.644381-9-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>
2023-04-10OvmfPkg: Update code to be more C11 compliant by using __func__Rebecca Cran1-3/+3
__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>
2022-04-04OvmfPkg: Revert Uncrustify formatting in VbeShim.h filesMichael Kubacki1-906/+905
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3875 Reverts changes automatically applied by Uncrustify in commit ac0a286. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
2021-12-07OvmfPkg: Apply uncrustify changesMichael Kubacki6-1259/+1291
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>
2021-12-07OvmfPkg: Change OPTIONAL keyword usage styleMichael D Kinney1-2/+1
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3760 Update all use of ', OPTIONAL' to ' OPTIONAL,' for function params. Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael Kubacki <michael.kubacki@microsoft.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Andrew Fish <afish@apple.com>
2020-11-30OvmfPkg/Bhyve: Fix various style issuesRebecca Cran2-8/+6
Fix ordering of includes, sources, libraries etc. Remove leading/trailing underscores from include guards. Change INF and DSC version numbers to be decimal. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201130053412.2-6-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
2020-08-19OvmfPkg: Fix spelling mistake for occurredMichael D Kinney1-1/+1
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2361 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Guomin Jiang <guomin.jiang@intel.com>
2020-08-01OvmfPkg: fix DEC spec violation introduced by Bhyve additionLaszlo Ersek1-1/+1
Sean reports that having two DEC files under OvmfPkg violates the DEC spec: > An EDK II Package (directory) is a directory that contains an EDK II > package declaration (DEC) file. Only one DEC file is permitted per > directory. EDK II Packages cannot be nested within other EDK II > Packages. This issue originates from commit 656419f922c0 ("Add BhyvePkg, to support the bhyve hypervisor", 2020-07-31). Remedy the problem as follows. (Note that these steps are not split to multiple patches in order to keep Bhyve buildable across the transition.) (1) Delete "OvmfPkg/Bhyve/BhyvePkg.dec". (2) Point the [Packages] sections of the Bhyve-specific AcpiPlatformDxe, BhyveRfbDxe, and BhyveFwCtlLib INF files to "OvmfPkg.dec". (3) Migrate the artifacts that "BhyvePkg.dec" used to have on top of "OvmfPkg.dec" as follows: (3a) Merge the copyright notices from Rebecca Cran and Pluribus Networks into "OvmfPkg.dec". (3b) Merge the "BhyveFwCtlLib" class header definition into "OvmfPkg.dec". (3c) Merge value 0x2F8 for the fixed PcdDebugIoPort into "BhyvePkgX64.dsc". (4) Unnest the the Include/Library/ and Library/ subtrees from under OvmfPkg/Bhyve to the corresponding, preexistent subtrees in OvmfPkg. The goal is to keep the [Includes] section in the "OvmfPkg.dec" file unchanged, plus simplify references in "BhyvePkgX64.dsc". Non-library modules remain under "OvmfPkg/Bhyve/". (4a) The BhyveFwCtlLib class header, and sole instance, are already uniquely named, so their movements need not involve file renames. (4b) Rename the Bhyve-specific PlatformBootManagerLib instance to PlatformBootManagerLibBhyve, in additon to moving it, for distinguishing it from OvmfPkg's preexistent lib instance. Apply the name change to all three of the lib instance directory name, the INF file, and the BASE_NAME define in the INF file. (4c) Update lib class resolutions in "BhyvePkgX64.dsc" accordingly. (5) Replace the "ACPI table storage" FILE_GUID in "OvmfPkg/Bhyve/AcpiTables/AcpiTables.inf" with a new GUID, and open-code the "ACPI table storage" GUID in the "ACPITABLE" FDF rule instead, replacing $(NAMED_GUID). This step is necessary because CI requires unique FILE_GUIDs over all INF files, and OVMF's original "AcpiTables.inf" already uses the "ACPI table storage" GUID as FILE_GUID. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Sean Brogan <spbrogan@outlook.com> Fixes: 656419f922c047a3c48bd3f4ecea7d8e87d0b761 Reported-by: Sean Brogan <spbrogan@outlook.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200801155024.16439-1-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
2020-07-31Add BhyvePkg, to support the bhyve hypervisorRebecca Cran9-0/+2947
BhyvePkg supports the bhyve hypervisor, which is a hypervisor/virtual machine manager available on FreeBSD, macOS and Illumos. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20200713054131.479627-2-rebecca@bsdio.com> Acked-by: Laszlo Ersek <lersek@redhat.com>