summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Fix erase blocks for SEV-ESTom Lendacky2020-11-101-2/+2
| | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 The original SEV-ES support missed updating the QemuFlashEraseBlock() function to successfully erase blocks. Update QemuFlashEraseBlock() to call the QemuFlashPtrWrite() to be able to successfully perform the commands under SEV-ES. Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <309c5317a3107bd0e650be20731842a2e1d4b59a.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Bypass flash detection with SEV-ESTom Lendacky2020-08-171-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 The flash detection routine will attempt to determine how the flash device behaves (e.g. ROM, RAM, Flash). But when SEV-ES is enabled and the flash device behaves as a ROM device (meaning it is marked read-only by the hypervisor), this check may result in an infinite nested page fault because of the attempted write. Since the instruction cannot be emulated when SEV-ES is enabled, the RIP is never advanced, resulting in repeated nested page faults. When SEV-ES is enabled, exit the flash detection early and assume that the FD behaves as Flash. This will result in QemuFlashWrite() being called to store EFI variables, which will also result in an infinite nested page fault when the write is performed. In this case, update QemuFlashWrite() to use the VMGEXIT MMIO write support to have the hypervisor perform the write without having to emulate the instruction. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: replace old EFI_D_ debug levels with new DEBUG_ onesRebecca Cran2020-04-301-7/+7
| | | | | | | | | | | | | 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: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-091-7/+1
| | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Clear C-bit when SEV is activeBrijesh Singh2018-03-091-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Commit:24e4ad7 (OvmfPkg: Add AmdSevDxe driver) added a driver which runs early in DXE phase and clears the C-bit from NonExistent entry -- which is later split and accommodate the flash MMIO. When SMM is enabled, we build two sets of page tables; first page table is used when executing code in non SMM mode (SMM-less-pgtable) and second page table is used when we are executing code in SMM mode (SMM-pgtable). During boot time, AmdSevDxe driver clears the C-bit from the SMM-less-pgtable. But when SMM is enabled, Qemu Flash services are used from SMM mode. In this patch we explicitly clear the C-bit from Qemu flash MMIO range before we probe the flash. When OVMF is built with SMM_REQUIRE then call to initialize the flash services happen after the SMM-pgtable is created and processor has served the first SMI. At this time we will have access to the SMM-pgtable. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> [lersek@redhat.com: trivial coding style improvements] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: adhere to -D SMM_REQUIRELaszlo Ersek2015-11-301-0/+1
| | | | | | | | | | | | | | When the user requires "security" by passing -D SMM_REQUIRE, and consequently by setting PcdSmmSmramRequire, enforce flash-based variables. Furthermore, add two ASSERT()s to catch if the wrong module were pulled into the build. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19063 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: clean up includes and librariesLaszlo Ersek2015-10-261-1/+1
| | | | | | | | | | | | | | | | | Before introducing the SMM driver interface, clean up #include directives and [LibraryClasses] by: - removing what's not directly used (HobLib and UefiLib), - adding what's used but not spelled out (DevicePathLib), - sorting the result. This helps with seeing each source file's dependencies and with determining the library classes for the SMM driver. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18672 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: split out runtime DXE specificsLaszlo Ersek2015-10-261-15/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for introducing an SMM interface to this driver, move the following traits to separate files, so that we can replace them in the new SMM INF file: - Protocol installations. The SMM driver will install protocol interfaces in the SMM protocol database, using SMM services. - Virtual address change handler and pointer conversions. SMM drivers run with physical mappings and pointers must not be converted. There are further restrictions and changes for an SMM driver, but the rest of the code either complies with those already, or will handle the changes transparently. For example: - SMM drivers have access to both UEFI and SMM protocols in their entry points (see the PI spec 1.4, "1.7 SMM Driver Initialization"), - MemoryAllocationLib has an SMM instance that serves allocation requests with the gSmst->SmmAllocatePool() service transparently, allocating runtime-marked SMRAM. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18671 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: rewrap source code to 79 charsLaszlo Ersek2015-10-261-3/+4
| | | | | | | | | | | | | | | | | | | Some of the line lengths in this driver are atrocious. While we have to put up with the status quo outside of OvmfPkg, we can at least rewrap this driver before refactoring it. In the FvbInitialize() function there's no way around introducing two local variables, just for the sake of sensibly rewrapping the code. Furthermore, in "FwBlockService.c" the function comment blocks are now indented; their original position causes diff to print bogus function names at the top of hunks. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18666 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: flash driver: drop needlessly wide multiplication (VS2010)Scott Duplichan2014-11-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current types of subexpressions used in QemuFlashPtr() are as follows. (We also show the types of "larger" subexpressions, according to operator binding.) mFlashBase + (Lba * mFdBlockSize) + Offset ^ ^ ^ ^ | | | | (UINT8*) EFI_LBA UINTN UINTN (UINT64) --------------------------------- ------ (UINT8*) UINTN ------------------------------------------ (UINT8*) When building with VS2010 for Ia32 / NOOPT, the 64-by-32 bit multiplication is translated to an intrinsic, which is not allowed in edk2. Recognize that "Lba" is always bounded by "mFdBlockCount" (an UINTN) here -- all callers of QemuFlashPtr() ensure that. In addition, the flash chip in question is always under 4GB, which is why we can address it at all on Ia32. Narrow "Lba" to UINTN, without any loss of range. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan <scott@notabs.org> [commit message by lersek@redhat.com] Signed-off-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16384 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: fix out-of-LBA write accessLaszlo Ersek2013-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When QemuFlashWrite() is asked to write a range that includes the last byte of the LBA, then the byte that the function uses to switch the flash device back to read mode (ROMD mode in KVM speak) actually falls out of the LBA. Normally this doesn't cause visible problems. However, if the variable store and the firmware code are backed by separate flash devices, as implemented by [Qemu-devel] [PATCH v2] hw/i386/pc_sysfw: support two flash drives http://thread.gmane.org/gmane.comp.emulators.qemu/243678 plus [edk2] [edk2 PATCH] OvmfPkg: split the variable store to a separate file http://thread.gmane.org/gmane.comp.bios.tianocore.devel/5045/focus=5046 then the READ_ARRAY_CMD not only reaches a different LBA, it reaches a different qemu device. This results in a guest reboot soon after. Fix this by ensuring that we always stay within the LBA just written when issuing READ_ARRAY_CMD. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14996 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add QemuFlashFvbServicesRuntimeDxe driverJordan Justen2013-11-121-0/+265
If QEMU flash is detected, this module will install FirmwareVolumeBlock support for the QEMU flash device. It will also set PCDs with the results that: 1. OvmfPkg/EmuVariableFvbRuntimeDxe will be disabled 2. MdeModulePkg variable services will read/write flash directly Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14839 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-27 11:01:30 +0000