summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: End timer interrupt later to avoid stack overflow under loadIgor Druzhinin2020-06-182-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | RestoreTPL called while at TPL_HIGH_LEVEL unconditionally enables interrupts even if called in interrupt handler. That opens a window while interrupt is not completely handled but another interrupt could be accepted. If a VM starts on a heavily loaded host hundreds of periodic timer interrupts might be queued while vCPU is descheduled (the behavior is typical for a Xen host). The next time vCPU is scheduled again all of them get delivered back to back causing OVMF to accept each one without finishing a previous one and cleaning up the stack. That quickly results in stack overflow and a triple fault. Fix it by postponing sending EOI until we finished processing the current tick giving interrupt handler opportunity to clean up the stack before accepting the next tick. Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com> Message-Id: <1592275782-9369-1-git-send-email-igor.druzhinin@citrix.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2815 Acked-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: add BZ ref; rewrap msg to silence PatchCheck.py]
* OvmfPkg/OvmfPkg*.dsc: Change PCDs type about status codeTan, Ming2020-06-184-12/+12
| | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2786 Since the type of PcdStatusCodeUseSerial and PcdStatusCodeUseMemory in MdeModulePkg.dec are changed, so change them from PcdsFeatureFlag to PcdsFixedAtBuild in dsc files. Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Ming Tan <ming.tan@intel.com>
* Revert "OvmfPkg: use generic QEMU image loader for secure boot enabled ..."Laszlo Ersek2020-06-163-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit ced77332cab626f35fbdb36630be27303d289d79. The command virt-install --location NETWORK-URL downloads the vmlinuz and initrd files from the remote OS tree, and passes them to the guest firmware via fw_cfg. When used with IA32 / X64 guests, virt-install expects the guest firmware to do two things, at the same time: - launch the fw_cfg kernel image even if the latter does not pass SB verification (SB checking is supposed to be bypassed entirely in favor of the Linux/x86 Boot Protocol), - still let the guest kernel perceive SB as enabled. Commit ced77332cab6 prevented this, by removing the Linux/x86 Boot Protocol from such an OVMF image that was built with SECURE_BOOT_ENALBE. While that's the right thing in theory, in practice "virt-install --location NETWORK-URL" is entrenched, and we shouldn't break it. We can tolerate the Linux/x86 Boot Protocol as a one-of-a-kind SB bypass for direct-booted kernels, because: - the fw_cfg content comes from QEMU, and the guest is already at QEMU's mercy, - in the guest, OS boots after the initial installation will use "shim" rather than an fw_cfg kernel, which we can consider somewhat similar to "Audit Mode / Deployed Mode" (~ trust for install, lock down after). Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Message-Id: <20200615144514.24597-1-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> [lersek@redhat.com: truncate the subject line, originally auto-generated by git-revert, to pacify PatchCheck.py]
* OvmfPkg/GenericQemuLoadImageLib: log "Not Found" at INFO levelLaszlo Ersek2020-06-101-1/+2
| | | | | | | | | | | | | gBS->LoadImage() returning EFI_NOT_FOUND is an expected condition; it means that QEMU wasn't started with "-kernel". Log this status code as INFO rather than ERROR. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200609105414.12474-1-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/X86QemuLoadImageLib: handle EFI_ACCESS_DENIED from LoadImage()Laszlo Ersek2020-06-091-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | When an image fails Secure Boot validation, LoadImage() returns EFI_SECURITY_VIOLATION if the platform policy is DEFER_EXECUTE_ON_SECURITY_VIOLATION. If the platform policy is DENY_EXECUTE_ON_SECURITY_VIOLATION, then LoadImage() returns EFI_ACCESS_DENIED (and the image does not remain loaded). (Before <https://bugzilla.tianocore.org/show_bug.cgi?id=2129>, this difference would be masked, as DxeImageVerificationLib would incorrectly return EFI_SECURITY_VIOLATION for DENY_EXECUTE_ON_SECURITY_VIOLATION as well.) In X86QemuLoadImageLib, proceed to the legacy Linux/x86 Boot Protocol upon seeing EFI_ACCESS_DENIED too. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2785 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200605235242.32442-1-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/Tcg2ConfigPei: restrict BaseLib class dependency to IA32 and X64Laszlo Ersek2020-06-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | BaseLib interfaces (namely, SwapBytesXx()) are only used in "Tpm12Support.c", which is IA32/X64-only. Therefore the BaseLib class dependency should also be restricted to IA32 & X64, in the INF file. The "#include <Library/BaseLib.h>" directive is already present in "Tpm12Support.c" only. (The BaseLib dependency should have been restricted to IA32 and X64 together with the Tpm12DeviceLib dependency, as part of commit 74f90d38c446, "OvmfPkg/Tcg2ConfigPei: skip TPM-1.2 detection when building for ARM/AARCH64", 2020-05-21.) This is a trivial cleanup; functionally a no-op. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2752 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200603170413.23936-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/Tcg2ConfigPei: generalize TPM2-only file-top commentsLaszlo Ersek2020-06-092-2/+2
| | | | | | | | | | | | | | | | | | | | The leading comments in "Tcg2ConfigPei.inf" and "Tcg2ConfigPeim.c" say, "In OvmfPkg, the module only performs TPM2 hardware detection". The statement hasn't been correct since commit 89236992913f ("OvmfPkg: detect TPM 1.2 in Tcg2ConfigPei", 2020-03-04). Replace "TPM2" with "TPM" (without stating a version) in those file-top comments. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2752 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200603170413.23936-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/Tcg2ConfigPei: skip TPM-1.2 detection when building for ARM/AARCH64Laszlo Ersek2020-05-213-2/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dating back to commits f5cb3767038e and ddd34a818315d, the "ArmVirtPkg/ArmVirtQemu.dsc" platform includes the "OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf" module when the TPM2_ENABLE build flag is defined. This was regressed in commit 89236992913f, which added a Tpm12DeviceLib dependency to Tcg2ConfigPei. "ArmVirtQemu.dsc" does not resolve that class to any instance, so now we get a build failure: > build.py... > ArmVirtPkg/ArmVirtQemu.dsc(...): error 4000: Instance of library class > [Tpm12DeviceLib] is not found > in [OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf] [AARCH64] > consumed by module [OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf] The TPM-1.2 code in OvmfPkg/Tcg2ConfigPei is limited to a special use case (a kind of physical TPM-1.2 assignment), and that has never applied to "ArmVirtQemu.dsc". Short-circuit the TPM-1.2 detection in the ARM/AARCH64 builds of OvmfPkg/Tcg2ConfigPei, removing the Tpm12DeviceLib dependency. Functionally, this patch is a no-op on IA32 / X64. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Eric Auger <eric.auger@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Simon Hardy <simon.hardy@itdev.co.uk> Cc: Stefan Berger <stefanb@linux.ibm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200520225841.17793-4-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/Tcg2ConfigPei: factor out InternalTpm12Detect()Laszlo Ersek2020-05-214-42/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | Move the calls to the Tpm12RequestUseTpm() and Tpm12SubmitCommand() Tpm12DeviceLib functions to a separate C file, so that we can override these actions in a subsequent patch. This code movement requires moving the TPM_RSP_GET_TICKS / TestTpm12() helper structure / function too. While at it, give the TestTpm12() function @retval / @return documentation, plus wrap an overlong line in it. Functionally, this patch is a no-op. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Eric Auger <eric.auger@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Simon Hardy <simon.hardy@itdev.co.uk> Cc: Stefan Berger <stefanb@linux.ibm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200520225841.17793-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/Tcg2ConfigPei: clean up some lib class dependenciesLaszlo Ersek2020-05-212-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 89236992913f introduced an explicit Tpm12CommandLib dependency to Tcg2ConfigPei. In reality this lib class is not consumed by Tcg2ConfigPei at all (such a dependency is not even inherited from other lib instances). Simplify the module by dropping the superfluous dependency. (The Tpm12CommandLib class resolution that was also added in commit 89236992913f is not useless, at the platform build level: it is consumed by TcgPei and TcgDxe. Meaning that said Tpm12CommandLib resolution should have likely been a part of the subsequent patch in the original series, namely commit 6be54f15a0c9.) Commit 89236992913f also introduced SwapBytesXx() calls. Those functions are provided by BaseLib. Spell out the BaseLib dependency. Functionally, this patch is a no-op. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Eric Auger <eric.auger@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Simon Hardy <simon.hardy@itdev.co.uk> Cc: Stefan Berger <stefanb@linux.ibm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200520225841.17793-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/PlatformPei: increase memory type info defaultsLaszlo Ersek2020-05-183-15/+15
| | | | | | | | | | | | | | | | | | | | | | | | | Any new OVMF binary (containing commit d42fdd6f8384, and built with SMM_REQUIRE) is likely to reboot during its first boot, regardless of whether the variable store is logically empty, or it contains a MemoryTypeInformation variable from an earlier OVMF binary. This "reboot on first boot after OVMF upgrade" occurs despite having eliminated BS Code/Data tracking in earlier parts of this series. Meaning that we've outgrown the bins of those memory types too that matter for SMM security. Eliminating said reboot will make an upgrade to edk2-stable202005 more comfortable for users. Increase the defaults empirically. (The total doesn't exceed 3MB by much.) Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200508121651.16045-5-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/PlatformPei: extract memory type info defaults to PCDsLaszlo Ersek2020-05-185-12/+52
| | | | | | | | | | | | | | | | | | | | Some OvmfPkg modules already depend on "EmbeddedPkg.dec"; thus, replace the open-coded memory type info defaults in the source code with the EmbeddedPkg PCDs that stand for the same purpose. Consequently, platform builders can override these values with the "--pcd" option of "build", without source code updates. While at it, sort the memory type names alphabetically. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200508121651.16045-4-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/PlatformPei: rewrite MemTypeInfo HOB production logicLaszlo Ersek2020-05-181-46/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous patch has no effect -- i.e., it cannot stop the tracking of BS Code/Data in MemTypeInfo -- if the virtual machine already has a MemoryTypeInformation UEFI variable. In that case, our current logic allows the DXE IPL PEIM to translate the UEFI variable to the HOB, and that translation is verbatim. If the variable already contains records for BS Code/Data, the issues listed in the previous patch persist for the virtual machine. For this reason, *always* install PlatformPei's own MemTypeInfo HOB. This prevents the DXE IPL PEIM's variable-to-HOB translation. In PlatformPei, consume the records in the MemoryTypeInformation UEFI variable as hints: - Ignore all memory types for which we wouldn't by default install records in the HOB. This hides BS Code/Data from any existent MemoryTypeInformation variable. - For the memory types that our defaults cover, enable the records in the UEFI variable to increase (and *only* to increase) the page counts. This lets the MemoryTypeInformation UEFI variable function as designed, but it eliminates a reboot when such a new OVMF binary is deployed (a) that has higher memory consumption than tracked by the virtual machine's UEFI variable previously, *but* (b) whose defaults also reflect those higher page counts. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200508121651.16045-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/PlatformPei: don't track BS Code/Data in default MemTypeInfo HOBLaszlo Ersek2020-05-181-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit d42fdd6f8384 ("OvmfPkg: improve SMM comms security with adaptive MemoryTypeInformation", 2020-03-12), we enabled the boot-to-boot tracking of the usages of various UEFI memory types. Both whitepapers listed in that commit recommend that BS Code/Data type memory *not* be tracked. This recommendation was confirmed by Jiewen in the following two messages as well: [1] https://edk2.groups.io/g/devel/message/55741 http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F97B579@shsmsx102.ccr.corp.intel.com [2] https://edk2.groups.io/g/devel/message/55749 http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F97BDC5@shsmsx102.ccr.corp.intel.com While tracking BS Code/Data type memory has one benefit (it de-fragments the UEFI memory map), the downsides outweigh it. Spikes in BS Data type memory usage are not uncommon in particular, and they may have the following consequences: - such reboots during normal boot that look "spurious" to the end user, and have no SMM security benefit, - a large BS Data record in MemoryTypeInformation may cause issues when the DXE Core tries to prime the according bin(s), but the system's RAM size has been reduced meanwhile. Removing the BS Code/Data entries from MemoryTypeInformation leads to a bit more fragmentation in the UEFI memory map, but that should be harmless. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200508121651.16045-2-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg: Skip initrd command on Xcode toolchainRoman Bolshakov2020-05-148-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | OVMF booting stops with the assert if built with Xcode on macOS: Loading driver at 0x0001FAB8000 EntryPoint=0x0001FABF249 LinuxInitrdDynamicShellCommand.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1F218398 ProtectUefiImageCommon - 0x1F218140 - 0x000000001FAB8000 - 0x0000000000008A60 ASSERT_EFI_ERROR (Status = Unsupported) ASSERT LinuxInitrdDynamicShellCommand.c(378): !EFI_ERROR (Status) The assert comes from InitializeHiiPackage() after an attempt to retrieve HII package list from ImageHandle. Xcode still doesn't support HII resource section and LinuxInitrdDynamicShellCommand depends on it. Likewise 277a3958d93a ("OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chain"), disable initrd command if built with Xcode toolchain Fixes: ec41733cfd10 ("OvmfPkg: add the 'initrd' dynamic shell command") Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Message-Id: <20200514134820.62047-1-r.bolshakov@yadro.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Use toolchain appropriate CpuExceptionHandlerLibLendacky, Thomas2020-05-114-0/+16
| | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2340 During the SEC phase, use the XCODE5 CpuExceptionHandlerLib library in place of the standard library when building with the XCODE5 toolchain. The SEC XCODE5 version of the library performs binary patching and should only be used when building with the XCODE5 toolchain. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <0cfdd51deb6d39e08380645f2022b9b76e29f66f.1588856809.git.thomas.lendacky@amd.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* OvmfPkg/MptScsiDxe: Reset device on ExitBootServices()Nikita Leshenko2020-05-051-1/+32
| | | | | | | | | | | This causes the device to forget about the reply frame. We allocated the reply frame in EfiBootServicesData type memory, and code executing after ExitBootServices() is permitted to overwrite it. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200504210607.144434-13-nikita.leshchenko@oracle.com>
* OvmfPkg/MptScsiDxe: Implement the PassThru methodNikita Leshenko2020-05-054-2/+423
| | | | | | | | | | | | Machines should be able to boot after this commit. Tested with different Linux distributions (Ubuntu, CentOS) and different Windows versions (Windows 7, Windows 10, Server 2016). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200504210607.144434-12-nikita.leshchenko@oracle.com> [lersek@redhat.com: MPT_SCSI_DMA_ADDR_HIGH: drop redundant space char]
* OvmfPkg/MptScsiDxe: Initialize hardwareNikita Leshenko2020-05-052-1/+325
| | | | | | | | | | | | | | Reset and send the IO controller initialization request. The reply is read back to complete the doorbell function but it isn't useful to us because it doesn't contain relevant data or status codes. See "LSI53C1030 PCI-X to Dual Channel Ultra320 SCSI Multifunction Controller" technical manual for more information. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Message-Id: <20200504210607.144434-11-nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/MptScsiDxe: Set and restore PCI attributesNikita Leshenko2020-05-051-1/+64
| | | | | | | | | | | | Enable the IO Space and Bus Mastering and restore the original values when the device is stopped. This is a standard procedure in PCI drivers. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Liran Alon <liran.alon@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200504210607.144434-10-nikita.leshchenko@oracle.com>
* OvmfPkg/MptScsiDxe: Open PciIo protocol for later useNikita Leshenko2020-05-051-1/+29
| | | | | | | | | | | This will give us an exclusive access to the PciIo of this device after it was started and until is will be stopped. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Liran Alon <liran.alon@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200504210607.144434-9-nikita.leshchenko@oracle.com>
* OvmfPkg/MptScsiDxe: Build and decode DevicePathNikita Leshenko2020-05-051-2/+59
| | | | | | | | | | Used to identify the individual disks in the hardware tree. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Liran Alon <liran.alon@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200504210607.144434-8-nikita.leshchenko@oracle.com>
* OvmfPkg/MptScsiDxe: Report targets and one LUNNikita Leshenko2020-05-053-2/+70
| | | | | | | | | | | | | | | The controller supports up to 8 targets in practice (Not reported by the controller, but based on the implementation of the virtual device), report them in GetNextTarget and GetNextTargetLun. The firmware will then try to communicate with them and create a block device for each one that responds. Support for multiple LUNs will be implemented in another series. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200504210607.144434-7-nikita.leshchenko@oracle.com>
* OvmfPkg/MptScsiDxe: Install stubbed EXT_SCSI_PASS_THRUNikita Leshenko2020-05-052-3/+183
| | | | | | | | | Support dynamic insertion and removal of the protocol Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200504210607.144434-6-nikita.leshchenko@oracle.com>
* OvmfPkg/MptScsiDxe: Probe PCI devices and look for MptScsiNikita Leshenko2020-05-053-1/+76
| | | | | | | | | | | | | The MptScsiControllerSupported function is called on handles passed in by the ConnectController() boot service and if the handle is the lsi53c1030 controller the function would return success. A successful return value will attach our driver to the device. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200504210607.144434-5-nikita.leshchenko@oracle.com>
* OvmfPkg/MptScsiDxe: Report name of driverNikita Leshenko2020-05-051-2/+59
| | | | | | | | | | | | Install Component Name protocols to have a nice display name for the driver in places such as UEFI shell. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200504210607.144434-4-nikita.leshchenko@oracle.com>
* OvmfPkg/MptScsiDxe: Install DriverBinding ProtocolNikita Leshenko2020-05-052-1/+67
| | | | | | | | | | | In order to probe and connect to the MptScsi device we need this protocol. Currently it does nothing. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200504210607.144434-3-nikita.leshchenko@oracle.com>
* OvmfPkg/MptScsiDxe: Create empty driverNikita Leshenko2020-05-058-0/+73
| | | | | | | | | | | In preparation for implementing LSI Fusion MPT SCSI devices, create a basic scaffolding for a driver. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Liran Alon <liran.alon@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200504210607.144434-2-nikita.leshchenko@oracle.com>
* OvmfPkg: Add BaseResetSystemLibBhyveRebecca Cran2020-05-053-0/+76
| | | | | | | | | | | | | | | Introduce BaseResetSystemLibBhyve.inf, to support powering off bhyve guests. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Message-Id: <20200504021853.76658-1-rebecca@bsdio.com> [lersek@redhat.com: MODULE_TYPE: replace DXE_DRIVER with BASE] [lersek@redhat.com: replace <OvmfPlatforms.h> with <IndustryStandard/Bhyve.h>] [lersek@redhat.com: strip ".inf" from subject line] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add QemuFwCfgLibNullRebecca Cran2020-05-052-0/+239
| | | | | | | | | | | | | | Add a null implementation library for QemuFwCfgLib, in order to support building PciHostBridgeLib for bhyve. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200503230910.26783-1-rebecca@bsdio.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add VBE2 mode info structure to LegacyVgaBios.hRebecca Cran2020-04-301-0/+38
| | | | | | | | | | | | bhyve uses the older VESA BIOS Extensions 2.0, so add the mode info structure to IndustryStandard/LegacyVgaBios.h Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Message-Id: <20200430011503.613044-1-rebecca@bsdio.com>
* OvmfPkg: Add bhyve support into AcpiTimerLibRebecca Cran2020-04-304-0/+79
| | | | | | | | | | | | | On bhyve, the ACPI timer is located at a fixed IO address; it need not be programmed into, nor fetched from, the PMBA -- power management base address -- register of the PCI host bridge. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Message-Id: <20200430011212.612386-1-rebecca@bsdio.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: replace old EFI_D_ debug levels with new DEBUG_ onesRebecca Cran2020-04-3064-357/+357
| | | | | | | | | | | | | 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: control PXEv4 / PXEv6 boot support from the QEMU command lineLaszlo Ersek2020-04-285-0/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a minimal, NULL class library called "PxeBcPcdProducerLib" for setting the "PcdIPv4PXESupport" and "PcdIPv6PXESupport" PCDs of NetworkPkg, from fw_cfg. These PCDs control whether the UefiPxeBcDxe driver supports PXEv4 / PXEv6 boot. If a PXE version is disabled, the corresponding LoadFile protocol instance is not produced by UefiPxeBcDxe, and so EfiBootManagerRefreshAllBootOption() in UefiBootManagerLib does not generate corresponding *new* boot options either. (Existent boot options are not deleted.) Hook the library into the UefiPxeBcDxe driver. (The driver is already included from "NetworkComponents.dsc.inc", but we can list it again in the DSC file, for providing <LibraryClasses> overrides.) In OVMF, the PCDs could be set in PlatformPei too, but ArmVirtQemu does not have fw_cfg access in the PEI phase. Hence a NULL class library that can be linked into UefiPxeBcDxe. When listing the PCDs under [PcdsDynamicDefault], stick with the DEC default values. QEMU switches: -fw_cfg name=opt/org.tianocore/IPv4PXESupport,string=[yn] -fw_cfg name=opt/org.tianocore/IPv6PXESupport,string=[yn] The "opt/org.tianocore" prefix follows the "opt/RFQDN/" recommendation from QEMU's "docs/specs/fw_cfg.txt". Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Per Sundstrom <per_sundstrom@yahoo.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200424075353.8489-6-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/QemuFwCfgDxeLib: allow UEFI_DRIVER modulesLaszlo Ersek2020-04-281-1/+1
| | | | | | | | | | | | | | | | | | | | We don't distribute UEFI_DRIVER modules stand-alone that were built as part of an OVMF platform. OVMF's UEFI_DRIVERs are allowed to inherit platform dependencies. By enabling UEFI_DRIVERs to consume QemuFwCfgDxeLib, we can hook fw_cfg-based NULL class libraries into UEFI drivers, e.g. in order to set dynamic PCDs. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Per Sundstrom <per_sundstrom@yahoo.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200424075353.8489-5-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/PlatformPei: use QemuFwCfgParseBool in UPDATE_BOOLEAN_PCD_FROM_...Laszlo Ersek2020-04-281-45/+2
| | | | | | | | | | | | | | | | | | The UPDATE_BOOLEAN_PCD_FROM_FW_CFG() macro currently calls the module-private helper function GetNamedFwCfgBoolean(). Replace the latter with QemuFwCfgParseBool() from QemuFwCfgSimpleParserLib. This change is compatible with valid strings accepted previously. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Per Sundstrom <per_sundstrom@yahoo.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200424075353.8489-4-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/PlatformPei: parse "X-PciMmio64Mb" with QemuFwCfgSimpleParserLibLaszlo Ersek2020-04-282-15/+22
| | | | | | | | | | | | | | | | | | | | | | | | Replace the - QemuFwCfgFindFile(), - QemuFwCfgSelectItem(), - QemuFwCfgReadBytes(), - AsciiStrDecimalToUint64() sequence in the GetFirstNonAddress() function with a call to QemuFwCfgSimpleParserLib. This change is compatible with valid strings accepted previously. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Per Sundstrom <per_sundstrom@yahoo.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200424075353.8489-3-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg: introduce QemuFwCfgSimpleParserLibLaszlo Ersek2020-04-287-0/+560
| | | | | | | | | | | | | | | | We already parse some boolean and integer values from named fw_cfg files (usually into PCDs), and we're going to cover more. Add a dedicated library for centralizing the parsing logic. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Per Sundstrom <per_sundstrom@yahoo.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200424075353.8489-2-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/OvmfXen: Introduce DEBUG_ON_HYPERVISOR_CONSOLE build flagAnthony PERARD2020-04-281-0/+11
| | | | | | | | | | | | Introduce DEBUG_ON_HYPERVISOR_CONSOLE build flag to enable logging debug output to the Xen console. This will work with both Xen HVM guest and Xen PVH guest whereas the default PlatformDebugLibIoPort works only in HVM when QEMU is present. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200423095358.2518197-6-anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformDebugLibIoPort: Introduce a Nocheck variantAnthony PERARD2020-04-282-0/+73
| | | | | | | | | Introduce PlatformRomDebugLibIoPortNocheck which doesn't try to detect the debug IO port. Instead, debug logs are always written to the IO port. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200423095358.2518197-5-anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformDebugLibIoPort: factor out debug port detectionAnthony PERARD2020-04-285-22/+36
| | | | | | | | | Factor out debug port detection in PlatformDebugLibIoPort. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200423095358.2518197-4-anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformDebugLibIoPort: Reword QEMU to hypervisorAnthony PERARD2020-04-284-4/+4
| | | | | | | | | | We are going to reuse PlatformDebugLibIoPort to use debug IO port from hypervisors that aren't QEMU, so reword "QEMU" to "hypervisor" in the descriptions. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200423095358.2518197-3-anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfXen: Remove DEBUG_ON_SERIAL_PORTAnthony PERARD2020-04-281-39/+1
| | | | | | | | | | | | | | | | | | | | Remove support for DEBUG_ON_SERIAL_PORT because OvmfXen can't be build with it due to a circular dependency: DebugLib : BaseDebugLibSerialPort -> SerialPortLib : XenConsoleSerialPortLib -> XenHypercallLib : XenHypercallLib -> DebugLib Also, if that dependency is fixed, I think it would be harder to find which console the debug is sent to when running an HVM guest. The xen console isn't the serial console used by default. Furthermore, XenHypercallLib isn't initialised early enough, so we would loose debug output from the SEC phase and early PEI phase. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200423095358.2518197-2-anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg: Add Platform CI and configuration for Core CISean Brogan2020-04-286-0/+766
| | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2570 Add new Azure Pipeline definitions to build and run OvmfPkg with: * Ubuntu GCC5 * Windows VS2019 Add PyTool based build of OvmfPkg Add extdep for managing the iasl dependency Add OvmfPkg.ci.yaml for Core CI Add ReadMe.md for details and instructions 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 Kubacki <michael.kubacki@microsoft.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com>
* OvmfPkg/ResetSystemLib: introduce the DxeResetSystemLib instanceLaszlo Ersek2020-04-227-1/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BaseResetSystemLib instance is not suitable for OS runtime, because its ResetShutdown() implementation calls PciRead16 (OVMF_HOSTBRIDGE_DID). On q35, this boils down to a memory-mapped config space access -- but we never ask the OS to map MMCONFIG for runtime. There are at least three alternatives to approach this: (1) Investigate "MdePkg/Library/DxeRuntimePciExpressLib", which offers some kind of runtime mapping for MMCONFIG. (2) Consume PciCf8Lib directly, rather than PciLib, in ResetSystemLib. Then we'll read OVMF_HOSTBRIDGE_DID from the config space with IO port accesses on q35 too, not just on i440fx. IO ports don't depend on page tables. (3) In the lib constructor, cache "mAcpiPmBaseAddress" based on "PcdOvmfHostBridgePciDevId" (which is set by PlatformPei). Then the host bridge type will be known at runtime without PCI config space accesses. This patch follows approach (3), in order to mirror AcpiTimerLib. Notes: * This patch is best viewed with "git show --find-copies-harder -C43". * PCDs are not usable in the DXE_CORE, as the PCD PPI is gone, and the PCD protocol is not available yet. (The DXE_CORE does consume ResetSystemLib in practice, when OVMF is built with -D SOURCE_DEBUG_ENABLE.) Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-7-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> [lersek@redhat.com: move third Note (with repro info) to BZ comment]
* OvmfPkg/ResetSystemLib: rename to BaseResetSystemLibLaszlo Ersek2020-04-226-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for introducing DxeResetSystemLib, rename the current (only) ResetSystemLib instance to BaseResetSystemLib. In the DSC files, keep the ResetSystemLib resolution in the same [LibraryClasses] section, but move it near the TimerLib resolution, as the differences between the ResetSystemLib instances will mostly follow those seen under OvmfPkg/Library/AcpiTimerLib. (While OvmfXen does not use "OvmfPkg/Library/AcpiTimerLib", perform the same movement there too, for keeping future DSC diffing simple.) Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-6-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* OvmfPkg/ResetSystemLib: factor out ResetShutdown()Laszlo Ersek2020-04-223-49/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the ResetShutdown() definition to its own file. This will help us introduce: - a new library instance that is not broken in runtime modules (the current library instance is broken in runtime modules), - another new library instance for bhyve support. While at it, squash AcpiPmControl() into ResetShutdown(), open-coding SuspendType=0. This is justified because we've had no other callers for AcpiPmControl() since commit 2d9950a2bff8 ("OvmfPkg: remove EnterS3WithImmediateWake () from ResetSystemLib", 2020-01-10). Tested with the "reset -s" UEFI shell command, on both i440fx and q35. 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> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-5-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* OvmfPkg/ResetSystemLib: improve coding style in ResetSystem()Laszlo Ersek2020-04-221-3/+3
| | | | | | | | | | | | | | | | | | | The cases under ResetSystem() currently mix "break"s with "return"s for no good reason. Use "break" consistently. (The inconsistency was introduced in commit 84c0b80de716, "OvmfPkg/ResetSystemLib: Add new API ResetSystem", 2019-04-28.) 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> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-4-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* OvmfPkg/ResetSystemLib: clean up library dependenciesLaszlo Ersek2020-04-222-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | Annotate the #include directives with the interfaces that this lib instance needs from the included lib class headers. This will help us keep the #include set minimal, when we move code around later. While at it, synchronize the [LibraryClasses] section with the #include directives -- list BaseLib. Also #include the ResetSystemLib class header, which declares the interfaces that this lib instance implements. This forces us to spell out the "MdeModulePkg.dec" dependency too, under [Packages]. 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> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-3-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* OvmfPkg/ResetSystemLib: wrap long linesLaszlo Ersek2020-04-222-10/+13
| | | | | | | | | | | | | | | Wrap the source code and the INF file at 79 characters. 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> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-2-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-13 15:52:28 +0000