summaryrefslogtreecommitdiff
path: root/OvmfPkg
AgeCommit message (Collapse)AuthorFilesLines
2018-08-16OvmfPkg: link Sha384 and Sha512 support into Tcg2Pei and Tcg2DxeGary Lin3-0/+12
Sha384 and Sha512 were added to HashInstanceLib recently. To make them available in Tcg2Pei and Tcg2Dxe, we have to link both libraries. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
2018-08-06OvmfPkg/PlatformDebugLibIoPort: fix port detection for use in the DXE CoreLaszlo Ersek1-4/+20
The DXE Core is one of those modules that call ProcessLibraryConstructorList() manually. Before DxeMain() [MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c] calls ProcessLibraryConstructorList(), and through it, our PlatformDebugLibIoPortConstructor() function, DxeMain() invokes the DEBUG() macro multiple times. That macro lands in our PlatformDebugLibIoPortFound() function -- which currently relies on the "mDebugIoPortFound" global variable that has (not yet) been set by the constructor. As a result, early debug messages from the DXE Core are lost. Move the device detection into PlatformDebugLibIoPortFound(), also caching the fact (not just the result) of the device detection. (We could introduce a separate DebugLib instance just for the DXE Core, but the above approach works for all modules that currently consume the PlatformDebugLibIoPort instance (which means "everything but SEC").) This restores messages such as: > CoreInitializeMemoryServices: > BaseAddress - 0x7AF21000 Length - 0x3CDE000 MinimalMemorySizeNeeded - 0x10F4000 Keep the empty constructor function -- OVMF's DebugLib instances have always had constructors; we had better not upset constructor dependency ordering by making our instance(s) constructor-less. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: c09d9571300a089c35f5df2773b70edc25050d0d Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> [lersek@redhat.com: sanitize blank lines around "mDebugIoPortChecked"]
2018-07-27OvmfPkg/PlatformBds: Implement PlatformBootManagerUnableToBootRuiyu Ni1-1/+60
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org>
2018-07-24OvmfPkg: Correct ResourcePublicationLib class name in DSC/INF filesLiming Gao4-4/+4
ResourcePublicationLib class name is ResourcePublicationLib. INF and DSC files are updated to use the correct one. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Signed-off-by: Dongao Guo <dongao.guo@intel.com> [lersek@redhat.com: insert empty line between commit msg body and tags] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-07-20OvmfPkg/XenPvBlkDxe: remove gEfiDevicePathProtocolGuid from [Protocols]Laszlo Ersek1-1/+0
XenPvBlkDxe doesn't reference gEfiDevicePathProtocolGuid; remove it from the INF file. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Steven Shi <steven.shi@intel.com> Reported-by: Steven Shi <steven.shi@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1034 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2018-07-19OvmfPkg/AcpiPlatformDxe: clean up libs and protos in "AcpiPlatformDxe.inf"Laszlo Ersek1-1/+1
None of the source files referenced by "AcpiPlatformDxe.inf" #include "MdePkg/Include/Library/DxeServicesLib.h" or use interfaces declared therein, so drop DxeServicesLib from [LibraryClasses]. "AcpiPlatformDxe.inf" references "AcpiPlatform.c", which installs ACPI tables built into the firmware image from under "OvmfPkg/AcpiTables/", in case dynamically generated ACPI tables are not available from Xen or QEMU. For this, the driver consumes gEfiFirmwareVolume2ProtocolGuid. Account for that in [Protocols]. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Steven Shi <steven.shi@intel.com> Reported-by: Steven Shi <steven.shi@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1014 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-07-06OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Restore C-bit when SEV is activeBrijesh Singh2-0/+18
AmdSevDxe maps the flash memory range with C=0, but SetMemorySpaceAttributes() unconditionally resets the C-bit to '1'. Lets restore the mapping back to C=0. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2018-07-06OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Do not expose MMIO in SMM buildBrijesh Singh4-50/+70
In the SMM build, only an SMM driver is using the address range hence we do not need to expose the flash MMIO range in EFI runtime mapping. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2018-07-06OvmfPkg/QemuFlashFvbServicesRuntimeDxe: mark Flash memory range as MMIOBrijesh Singh1-8/+22
The flash memory range is an IO address and should be presented as Memory Mapped IO in EFI Runtime mapping. This information can be used by OS when mapping the flash memory range. It is especially helpful in SEV guest case, in which IO addresses should be mapped as unencrypted. If memory region is not marked as MMIO then OS maps the range as encrypted. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2018-06-29OvmfPkg: Removing ipf which is no longer supported from edk2.chenc225-50/+53
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-14OvmfPkg: add QemuRamfb to platform consoleGerd Hoffmann1-0/+51
Add QemuRamfbDxe device path to the list of platform console devices, so ConSplitter will pick up the device even though it isn't a PCI GPU. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2018-06-14OvmfPkg: add QemuRamfbDxeGerd Hoffmann8-0/+459
Add a driver for the qemu ramfb display device. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> [lersek@redhat.com: fix INF banner typo] [lersek@redhat.com: make some local variable definitions more idiomatic] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2018-06-14OvmfPkg: add QEMU_RAMFB_GUIDGerd Hoffmann2-0/+26
Add GUID header file for the QemuRamfbDxe driver. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2018-05-29OvmfPkg/PlatformBootManagerLib: add missing report status code callArd Biesheuvel2-0/+5
Consumers of status code reports may rely on a status code to be reported when the ReadyToBoot event is signalled. For instance, FirmwarePerformanceDxe will fail to install the FPDT ACPI table in this case. So add the missing call. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-05-29OvmfPkg BasePciCapLib: Fix VS build failureLiming Gao1-2/+2
Fix VS warning C4244: 'function': conversion from 'UINT32' to 'UINT16', possible loss of data. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: remove whitespace after casts] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-05-29OvmfPkg: raise DXEFV size to 11 MBLaszlo Ersek3-9/+9
Almost exactly two years after commit 2f7b34b20842f, we've grown out the 10MB DXEFV: > build -a IA32 -a X64 -p OvmfPkg/OvmfPkgIa32X64.dsc -b NOOPT -t GCC48 \ > -D SMM_REQUIRE -D SECURE_BOOT_ENABLE -D TLS_ENABLE -D E1000_ENABLE \ > -D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE > > [...] > > GenFv: ERROR 3000: Invalid > the required fv image size 0xa28d48 exceeds the set fv image size > 0xa00000 Raise the DXEFV size to 11MB. (For builds that don't need this DXEFV bump, I've checked the FVMAIN_COMPACT increase stemming from the additional 1MB padding, using NOOPT + GCC48 + FD_SIZE_2MB, and no other "-D" flags. In the IA32 build, FVMAIN_COMPACT grows by 232 bytes. In the IA32X64 build, FVMAIN_COMPACT shrinks by 64 bytes. In the X64 build, FVMAIN_COMPACT shrinks by 376 bytes.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Gary Lin <glin@suse.com>
2018-05-24OvmfPkg/Virtio10Dxe: convert to PciCapLibLaszlo Ersek3-93/+53
Replace the manual capability list parsing in OvmfPkg/Virtio10Dxe with PciCapLib and PciCapPciIoLib API calls. The VIRTIO_PCI_CAP_LINK structure type is now superfluous. (Well, it always has been; we should have used EFI_PCI_CAPABILITY_HDR.) Also, EFI_PCI_CAPABILITY_VENDOR_HDR is now included at the front of VIRTIO_PCI_CAP. No driver other than Virtio10Dxe relies on VIRTIO_PCI_CAP. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-05-24OvmfPkg/PciHotPlugInitDxe: convert to PciCapLibLaszlo Ersek2-171/+103
Replace the manual capability list parsing in OvmfPkg/PciHotPlugInitDxe with PciCapLib and PciCapPciSegmentLib API calls. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-05-24OvmfPkg: resolve PciCapLib, PciCapPciSegmentLib, PciCapPciIoLibLaszlo Ersek3-0/+9
Resolve the PciCapLib, PciCapPciSegmentLib, and PciCapPciIoLib classes to their single respective instances. Later patches will use these lib classes in OvmfPkg drivers. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-05-24OvmfPkg: introduce PciCapPciIoLibLaszlo Ersek5-0/+386
Add a library class, and a UEFI_DRIVER lib instance, that are layered on top of PciCapLib, and allow clients to plug an EFI_PCI_IO_PROTOCOL backend into PciCapLib, for config space access. (Side note: Although the UEFI spec says that EFI_PCI_IO_PROTOCOL_CONFIG() returns EFI_UNSUPPORTED if "[t]he address range specified by Offset, Width, and Count is not valid for the PCI configuration header of the PCI controller", this patch doesn't directly document the EFI_UNSUPPORTED error code, for ProtoDevTransferConfig() and its callers ProtoDevReadConfig() and ProtoDevWriteConfig(). Instead, the patch refers to "unspecified error codes". The reason is that in edk2, the PciIoConfigRead() and PciIoConfigWrite() functions [1] can also return EFI_INVALID_PARAMETER for the above situation. Namely, PciIoConfigRead() and PciIoConfigWrite() first call PciIoVerifyConfigAccess(), which indeed produces the standard EFI_UNSUPPORTED error code, if the device's config space is exceeded. However, if PciIoVerifyConfigAccess() passes, and we reach RootBridgeIoPciRead() and RootBridgeIoPciWrite() [2], then RootBridgeIoCheckParameter() can still fail, e.g. if the root bridge doesn't support extended config space (see commit 014b472053ae3). For all kinds of Limit violations in IO, MMIO, and config space, RootBridgeIoCheckParameter() returns EFI_INVALID_PARAMETER, not EFI_UNSUPPORTED. That error code is then propagated up to, and out of, PciIoConfigRead() and PciIoConfigWrite(). [1] MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c [2] MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c ) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-05-24OvmfPkg: introduce PciCapPciSegmentLibLaszlo Ersek5-0/+395
Add a library class, and a BASE lib instance, that are layered on top of PciCapLib, and allow clients to plug a PciSegmentLib backend into PciCapLib, for config space access. (Side note: The "MaxDomain" parameter is provided because, in practice, platforms exist where a PCI Express device may show up on a root bridge such that the root bridge doesn't support access to extended config space. Earlier the same issue was handled for MdeModulePkg/PciHostBridgeDxe in commit 014b472053ae3. However, that solution does not apply to the PciSegmentLib class, because: (1) The config space accessor functions of the PciSegmentLib class, such as PciSegmentReadBuffer(), have no way of informing the caller whether access to extended config space actually succeeds. (For example, in the UefiPciSegmentLibPciRootBridgeIo instace, which could in theory benefit from commit 014b472053ae3, the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() status code is explicitly ignored, because there's no way for the lib instance to propagate it to the PciSegmentLib caller. If the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() call fails, then DxePciSegmentLibPciRootBridgeIoReadWorker() returns Data with indeterminate value.) (2) There is no *general* way for any firmware platform to provide, or use, a PciSegmentLib instance in which access to extended config space always succeeds. In brief, on a platform where config space may be limited to 256 bytes, access to extended config space through PciSegmentLib may invoke undefined behavior; therefore PciCapPciSegmentLib must give platforms a way to prevent such access.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-05-24OvmfPkg: introduce PciCapLibLaszlo Ersek5-0/+1540
Add a library class, and a BASE lib instance, to work more easily with PCI capabilities in PCI config space. Functions are provided to parse capabilities lists, and to locate, describe, read and write capabilities. PCI config space access is abstracted away. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-05-22OvmfPkg/PlatformBootManagerLib: process TPM PPI requestMarc-André Lureau2-0/+8
Call Tcg2PhysicalPresenceLibProcessRequest() to process pending PPI requests from PlatformBootManagerAfterConsole(). Laszlo understanding of edk2 is that the PPI operation processing was meant to occur *entirely* before End-Of-Dxe, so that 3rd party UEFI drivers couldn't interfere with PPI opcode processing *at all*. He suggested that we should *not* call Tcg2PhysicalPresenceLibProcessRequest() from BeforeConsole(). Because, an "auth" console, i.e. one that does not depend on a 3rd party driver, is *in general* impossible to guarantee. Instead we could opt to trust 3rd party drivers, and use the "normal" console(s) in AfterConsole(), in order to let the user confirm the PPI requests. It will depend on the user to enable Secure Boot, so that the trustworthiness of those 3rd party drivers is ensured. If an attacker roots the guest OS from within, queues some TPM2 PPI requests, and also modifies drivers on the EFI system partition and/or in GPU option ROMs (?), then those drivers will not load after guest reboot, and thus the dependent console(s) won't be used for confirming the PPI requests. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-05-22OvmfPkg: add Tcg2PhysicalPresenceLibQemuMarc-André Lureau6-3/+1046
Cloned "SecurityPkg/Library/DxeTcg2PhysicalPresenceLib" and: - removed all the functions that are unreachable from Tcg2PhysicalPresenceLibProcessRequest() [called from platform BDS], or SubmitRequestToPreOSFunction() and ReturnOperationResponseToOsFunction() [called from Tcg2Dxe]. - replaced everything that's related to the TCG2_PHYSICAL_PRESENCE*_VARIABLE variables, with direct access to the QEMU structures. This commit is based on initial experimental work from Stefan Berger. In particular, he wrote most of QEMU PPI support, and designed the qemu/firmware interaction. Initially, Stefan tried to reuse the existing SecurityPkg code, but we eventually decided to get rid of the variables and simplify the ovmf/qemu version. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> [lersek@redhat.com: clean up non-idiomatic coding style] [lersek@redhat.com: null mPpi on invalid PPI address] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-05-22OvmfPkg/IndustryStandard: add QemuTpm.h headerMarc-André Lureau1-0/+69
Add some common macros and type definitions corresponding to the QEMU TPM interface. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2018-05-22OvmfPkg: add Tcg2PhysicalPresenceLibNull when !TPM2_ENABLEMarc-André Lureau5-0/+66
This NULL library will let us call Tcg2PhysicalPresenceLibProcessRequest() unconditionally from BdsPlatform when building without TPM2_ENABLE. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> [lersek@redhat.com: replace MdeModulePkg.dec w/ MdePkg.dec] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-05-18OvmfPkg/PlatformBootManagerLib: connect Virtio RNG devices againLaszlo Ersek2-0/+106
Virtio RNG devices are never boot devices, so in commit 245c643cc8b7 we stopped connecting them. This is a problem because an OS boot loader may depend on EFI_RNG_PROTOCOL to seed the OS's RNG. Connect Virtio RNG devices again. And, while commit 245c643cc8b7 removed that from PlatformBootManagerAfterConsole(), reintroduce it now to PlatformBootManagerBeforeConsole() -- this way Driver#### options launched between both functions may access EFI_RNG_PROTOCOL too. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: 245c643cc8b73240c3b88cb55b2911b285a8c10d Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1579518 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-05-17OvmfPkg/QemuVideoDxe: Enable DISPLAY_OTHER pci class for qemu stdvgaGerd Hoffmann1-0/+6
This makes QemuVideo bind to the secondary-vga device. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-05-17OvmfPkg/QemuVideoDxe: Add SubClass field to QEMU_VIDEO_CARDGerd Hoffmann2-4/+14
Then check for PCI_CLASS_DISPLAY_VGA using the new field. This allows to enable/disable non-vga display classes per card entry. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-05-14OvmfPkg/PlatformBootManagerLib: connect consoles unconditionallyLaszlo Ersek1-83/+44
If both ConIn and ConOut exist, but ConIn references none of the PS/2 keyboard, the USB wild-card keyboard, and any serial ports, then PlatformInitializeConsole() currently allows the boot to proceed without any input devices at all. This makes for a bad user experience -- the firmware menu could only be entered through OsIndications, set by a guest OS. Do what ArmVirtQemu does already, namely connect the consoles, and add them to ConIn / ConOut / ErrOut, unconditionally. (The underlying EfiBootManagerUpdateConsoleVariable() function checks for duplicates.) The issue used to be masked by the EfiBootManagerConnectAll() call that got conditionalized in commit 245c643cc8b7. This patch is best viewed with "git show -b -W". Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: 245c643cc8b73240c3b88cb55b2911b285a8c10d Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1577546 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-04-26OvmfPkg/QemuVideoDxe: round up FrameBufferSize to full pageGerd Hoffmann1-0/+6
Guests do the same, because the framebuffer is mapped somewhere, which obviously works with page granularity only. When not rounding up to full page size we get messages like this one (linux kernel): efifb: framebuffer at 0x80000000, using 1876k, total 1875k ^^^^^ ^^^^^ Also sysfb is confused and throws an error: sysfb: VRAM smaller than advertised Cc: Phil Dennis-Jordan <phil@philjordan.eu> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: fix coding style]
2018-04-24OvmfPkg/README: add HTTPS BootGary Lin1-0/+88
Add the new section for HTTPS Boot. Changes in v2: - Fixed the typos - Added the command for p11-kit based on Laszlo's suggestion - Also added the efisiglist command - Elaborated how to create the customized cipher suite list - Mentioned the changes in QEMU in the future based on Laszlo's suggestion Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: trivial typo fixes; update-crypto-policies URL fix]
2018-04-16OvmfPkg/PlatformBootManagerLib: add USB keyboard to ConInLaszlo Ersek1-0/+32
PlatformInitializeConsole() (called by PlatformBootManagerBeforeConsole()) adds elements of "gPlatformConsole" to ConIn / ConOut / ErrOut (as requested per element) if at boot at least one of ConIn and ConOut doesn't exist. This typically applies to new VMs, and VMs with freshly recreated varstores. Add a USB keyboard wildcard to ConIn via "gPlatformConsole", so that we not only bind the PS/2 keyboard. (The PS/2 keyboard is added in PrepareLpcBridgeDevicePath()). Explicitly connecting the USB keyboard is necessary after commit 245c643cc8b7. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-04-13OvmfPkg/TlsAuthConfigLib: configure trusted cipher suites for HTTPS bootLaszlo Ersek2-1/+100
Read the list of trusted cipher suites from fw_cfg and to store it to EDKII_HTTP_TLS_CIPHER_LIST_VARIABLE. The fw_cfg file will be formatted by the "update-crypto-policies" utility on the host side, so that the host settings take effect in guest HTTPS boot as well. QEMU forwards the file intact to the firmware. The contents are forwarded by NetworkPkg/HttpDxe (in TlsConfigCipherList()) to NetworkPkg/TlsDxe (TlsSetSessionData()) and TlsLib (TlsSetCipherList()). Note: the development of the "update-crypto-policies" feature is underway at this time. Meanwhile the following script can be used to generate the binary file for fw_cfg: export LC_ALL=C openssl ciphers -V \ | sed -r -n \ -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \ | xargs -r -- printf -- '%b' > ciphers.bin Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Long Qin <qin.long@intel.com> Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com> [lersek@redhat.com: update commit msg and add script as requested by Gary] [lersek@redhat.com: update commit msg as requested by Jiaxin]
2018-04-10OvmfPkg: remove BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxeLaszlo Ersek12-1149/+0
BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxe were introduced to OvmfPkg in March 2010, in adjacent commits b0f5144676fa and efd82c5794ec. In the past eight years, no driver or application seems to have materialized that produced BLOCK_MMIO_PROTOCOL instances. Meanwhile the UEFI spec has developed the EFI_RAM_DISK_PROTOCOL, which edk2 implements (and OVMF includes) as RamDiskDxe. Rather than fixing issues in the unused BlockMmioToBlockIoDxe driver, remove the driver, together with the BLOCK_MMIO_PROTOCOL definition that now becomes unused too. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Steven Shi <steven.shi@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=926 Reported-by: Steven Shi <steven.shi@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>
2018-03-30OvmfPkg/TlsAuthConfigLib: configure trusted CA certs for HTTPS bootLaszlo Ersek5-3/+224
Introduce TlsAuthConfigLib to read the list of trusted CA certificates from fw_cfg and to store it to EFI_TLS_CA_CERTIFICATE_VARIABLE. The fw_cfg file is formatted by the "p11-kit" and "update-ca-trust" utilities on the host side, so that the host settings take effect in guest HTTPS boot as well. QEMU forwards the file intact to the firmware. The contents are sanity-checked by NetworkPkg/HttpDxe code that was added in commit 0fd13678a681. Link TlsAuthConfigLib via NULL resolution into TlsAuthConfigDxe. This sets EFI_TLS_CA_CERTIFICATE_VARIABLE in time for both NetworkPkg/TlsAuthConfigDxe (for possible HII interaction with the user) and for NetworkPkg/HttpDxe (for the effective TLS configuration). The file formatted by "p11-kit" can be large. On a RHEL-7 host, the the Mozilla CA root certificate bundle -- installed with the "ca-certificates" package -- is processed into a 182KB file. Thus, create EFI_TLS_CA_CERTIFICATE_VARIABLE as a volatile & boot-time only variable. Also, in TLS_ENABLE builds, set the cumulative limit for volatile variables (PcdVariableStoreSize) to 512KB, and the individual limit for the same (PcdMaxVolatileVariableSize) to 256KB. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-03-30OvmfPkg: annotate "PcdVariableStoreSize := PcdFlashNvStorageVariableSize"Laszlo Ersek3-0/+6
As a continuation of the last patch, clarify in the DSC files that we set PcdVariableStoreSize to the same value as PcdFlashNvStorageVariableSize just for convenience; the equality is not a technical requirement. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-03-30OvmfPkg/EmuVariableFvbRuntimeDxe: stop using PcdVariableStoreSizeLaszlo Ersek2-5/+4
In commit 62f43f7c1947c, we set PcdVariableStoreSize to the same value as PcdFlashNvStorageVariableSize (which in turn comes from VARS_LIVE_SIZE in "OvmfPkg.fdf.inc"). This equality between both PCDs is a false requirement from EmuVariableFvbRuntimeDxe. FVB drivers should use PcdFlashNvStorageVariableSize for supporting non-volatile variables (even if they happen to be kept in RAM only), along the other PcdFlashNvStorage* PCDs. Whereas PcdVariableStoreSize is for variables that are volatile at the gRT->SetVariable() / gRT->GetVariable() API level. (PlatformPei too bases the preallocation for EmuVariableFvbRuntimeDxe on PcdFlashNvStorageFtwSpareSize.) Replace PcdVariableStoreSize in EmuVariableFvbRuntimeDxe with the same-value PcdFlashNvStorageVariableSize. This means no change in behavior, and it allows us to increase PcdVariableStoreSize in a later patch without disturbing EmuVariableFvbRuntimeDxe (or PlatformPei). Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-03-28OvmfPkg/PlatformPei: debug log "etc/reserved-memory-end" from fw_cfgLaszlo Ersek1-0/+2
QEMU calculates the UINT64 value in "etc/reserved-memory-end" in a quite complex way, in the pc_memory_init() function. Log the value as a DEBUG_VERBOSE message to support debugging. Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1353591 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-03-28OvmfPkg:Fix VS2012 build failureDandan Bi3-3/+24
Initialize local variable to suppress warning C4701/C4703: potentially uninitialized local variable/pointer variable. 1.In VirtualMemory.c: Read of "PageMapLevel4Entry" in SetMemoryEncDe() is only reached when "PageMapLevel4Entry" is got correctly. 2.In VirtioBlk.c: Reads (dereferences) of "BufferMapping" and "BufferDeviceAddress" in SynchronousRequest() are only reached if "BufferSize > 0" *and* we map the data buffer successfully. 3.In VirtioScsi.c: Reads (dereferences) of "InDataMapping" and "InDataDeviceAddress", in VirtioScsiPassThru() are only reached if "Packet->InTransferLength > 0" on input, *and* we map the input buffer successfully. The similar reason for "OutDataMapping" and "OutDataDeviceAddress". Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-03-26OvmfPkg/QemuVideoDxe: handle invalid BltOperation gracefullyLaszlo Ersek1-1/+1
According to the UEFI spec, EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt() is supposed to catch an invalid BltOperation, and report it with EFI_INVALID_PARAMETER. Remove the assertion from QemuVideoGraphicsOutputBlt() that prevents this from working in NOOPT and DEBUG builds. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Rocky <xingrong.ni@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Reported-by: Rocky <xingrong.ni@intel.com> Analyzed-by: Ruiyu Ni <ruiyu.ni@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=897 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
2018-03-16OvmfPkg/PlatformBootManagerLib: process "-kernel" before boot devicesLaszlo Ersek1-4/+4
This improves the UEFI boot time for VMs that have "-kernel", many disks or NICs, and no "bootindex" properties. (Unlike in ArmVirt commit 23d04b58e27b, in OvmfPkg commit 52fba28994e9 we introduced TryRunningQemuKernel() right from the start *after* BdsLibConnectAll(). Therefore, unlike in patch 'ArmVirtPkg/PlatformBootManagerLib: return to "-kernel before boot devices"', we adopt the logic as new in this patch.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Gabriel Somlo <gsomlo@gmail.com>
2018-03-16OvmfPkg/PlatformBootManagerLib: hoist PciAcpiInitialization()Laszlo Ersek1-2/+5
PlatformBootManagerAfterConsole() <--------------------------------+ PlatformBdsConnectSequence() | ConnectDevicesFromQemu() / EfiBootManagerConnectAll() | PciAcpiInitialization() ---------------------------------+ TryRunningQemuKernel() Functionally this is a no-op: - PciAcpiInitialization() iterates over PciIo protocol instances, which are available just the same at the new call site. - The PCI interrupt line register exists only to inform system software (it doesn't affect hardware) and UEFI drivers don't use PCI interrupts anyway. (More background in commits 2e70cf8ade0d and 5218c27950c4.) This change will let us move TryRunningQemuKernel() between PciAcpiInitialization() and PlatformBdsConnectSequence() in the next patch. Cc: "Gabriel L. Somlo" <gsomlo@gmail.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <gsomlo@gmail.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Gabriel Somlo <gsomlo@gmail.com>
2018-03-16OvmfPkg/PlatformBootManagerLib: rejuvenate old-style function commentsLaszlo Ersek1-102/+70
The old-style "Routine Description: ..." comments use the leftmost column and are placed between the parameter list and the function body. Therefore they cause git-diff to produce bogus hunk headers that fail to name the function being patched. Convert these comment blocks to the current edk2 style. While at it, clean them up too. For PlatformBootManagerBeforeConsole() and PlatformBootManagerAfterConsole(), copy the descriptions from the call sites in "MdeModulePkg/Universal/BdsDxe/BdsEntry.c". They are more detailed than the comments in the lib class header "MdeModulePkg/Include/Library/PlatformBootManagerLib.h"; ArmVirtPkg already uses these comments. No functional changes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Gabriel Somlo <gsomlo@gmail.com>
2018-03-16OvmfPkg/PlatformBootManagerLib: wrap overlong lines in "BdsPlatform.c"Laszlo Ersek1-28/+51
No functional changes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Gabriel Somlo <gsomlo@gmail.com>
2018-03-15OvmfPkg/PciHostBridgeLib: clear PCI aperture vars for (re)initHeyi Guo2-1/+10
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-14OvmfPkg/PlatformBootManagerLib: minimize the set of connected devicesLaszlo Ersek1-6/+10
Prefer ConnectDevicesFromQemu() to EfiBootManagerConnectAll(). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Xiang Zheng <xiang.zheng@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
2018-03-14OvmfPkg/QemuBootOrderLib: add ConnectDevicesFromQemu()Laszlo Ersek2-4/+189
QemuBootOrderLib expects PlatformBootManagerLib to call the following triplet: (1) EfiBootManagerConnectAll(), (2) EfiBootManagerRefreshAllBootOption(), (3) SetBootOrderFromQemu(). This leads to bad performance, when many devices exist such that the firmware can drive them, but they aren't marked for booting in the "bootorder" fw_cfg file. Namely, (1) EfiBootManagerConnectAll() talks to all hardware, which takes long. Plus some DriverBindingStart() functions write NV variables, which is also slow. (For example, the IP config policy for each NIC is stored in an NV var that is named after the MAC). (2) EfiBootManagerRefreshAllBootOption() generates boot options from the protocol instances produced by (1). Writing boot options is slow. (3) Under the above circumstances, SetBootOrderFromQemu() removes most of the boot options produced by (2). Erasing boot options is slow. Introduce ConnectDevicesFromQemu() as a replacement for (1): only connect devices that the QEMU user actually wants to boot off of. (There's a slight loss of compatibility when a platform switches from EfiBootManagerConnectAll() to ConnectDevicesFromQemu(). EfiBootManagerConnectAll() may produce UEFI device paths that are unknown to QemuBootOrderLib (that is, for neither PCI- nor virtio-mmio-based devices). The BootOrderComplete() function lets such unmatched boot options survive at the end of the boot order. With ConnectDevicesFromQemu(), these options will not be auto-generated in the first place. They may still be produced by other means. SetBootOrderFromQemu() is not modified in any way; reordering+filtering boot options remains a separate task.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Xiang Zheng <xiang.zheng@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
2018-03-14OvmfPkg/QemuBootOrderLib: clean up translation of virtio-net over MMIOLaszlo Ersek1-3/+3
The "/MAC(" suffix of the translated UEFI devpath prefix is unnecessary for matching, because the virtio-mmio base address in VenHwString is unique anyway. Furthermore, the partial string "MAC(" cannot be processed by ConvertTextToDevicePath(), which will become relevant later in this series. Remove "/MAC(". While at it, remove a bogus comment on PCI. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Xiang Zheng <xiang.zheng@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
2018-03-14OvmfPkg/QemuBootOrderLib: add missing EFIAPI specifiersLaszlo Ersek2-0/+4
Public library APIs should be declared as EFIAPI. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Xiang Zheng <xiang.zheng@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
generated by cgit v1.1 at 2024-11-08 08:56:05 +0000