summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/QemuFlashFvbServicesRuntimeDxe
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Use physical address with SEV-ESTom Lendacky2021-01-261-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3183 Under SEV-ES, a write to the flash device is done using a direct VMGEXIT to perform an MMIO write. The address provided to the MMIO write must be the physical address of the MMIO write destitnation. During boot, OVMF runs with an identity mapped pagetable structure so that VA == PA and the VMGEXIT MMIO write destination is just the virtual address of the flash area address being written. However, when the UEFI SetVirtualAddressMap() API is invoked, an identity mapped pagetable structure may not be in place and using the virtual address for the flash area address is no longer valid. This results in writes to the flash not being performed successfully. This can be seen by attempting to change the boot order under Linux. The update will appear to be performed, based on the output of the command. But rebooting the guest will show that the new boot order has not been set. To remedy this, save the value of the flash base physical address before converting the address as part of SetVirtualAddressMap(). The physical address can then be calculated by obtaining the offset of the MMIO target virtual address relative to the flash base virtual address and adding that to the original flash base physical address. The resulting value produces a successful MMIO write during runtime services. Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <84a5f9161541db5aa3b57c96b737afbcb4b6189d.1611410263.git.thomas.lendacky@amd.com> [lersek@redhat.com: SetVitualAddressMap() -> SetVirtualAddressMap() typo fix, in both the commit message and the code comment] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg, OvmfPkg: Disable interrupts when using the GHCBTom Lendacky2020-11-101-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 The QemuFlashPtrWrite() flash services runtime uses the GHCB and VmgExit() directly to perform the flash write when running as an SEV-ES guest. If an interrupt arrives between VmgInit() and VmgExit(), the Dr7 read in the interrupt handler will generate a #VC, which can overwrite information in the GHCB that QemuFlashPtrWrite() has set. This has been seen with the timer interrupt firing and the CpuExceptionHandlerLib library code, UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ Xcode5ExceptionHandlerAsm.nasm and ExceptionHandlerAsm.nasm reading the Dr7 register while QemuFlashPtrWrite() is using the GHCB. In general, it is necessary to protect the GHCB whenever it is used, not just in QemuFlashPtrWrite(). Disable interrupts around the usage of the GHCB by modifying the VmgInit() and VmgDone() interfaces: - VmgInit() will take an extra parameter that is a pointer to a BOOLEAN that will hold the interrupt state at the time of invocation. VmgInit() will get and save this interrupt state before updating the GHCB. - VmgDone() will take an extra parameter that is used to indicate whether interrupts are to be (re)enabled. Before exiting, VmgDone() will enable interrupts if that is requested. Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <c326a4fd78253f784b42eb317589176cf7d8592a.1604685192.git.thomas.lendacky@amd.com>
* 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: Set the SwScratch valid bitTom Lendacky2020-11-101-0/+1
| | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 All fields that are set in the GHCB should have their associated bit in the GHCB ValidBitmap field set. Add support to set the bit for the scratch area field (SwScratch). 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: <cc8c8449740d2be0b287e6c69d48bf6cb067c7d8.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Bypass flash detection with SEV-ESTom Lendacky2020-08-175-3/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-304-15/+15
| | | | | | | | | | | | | 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: set fixed FlashNvStorage base addresses with -D SMM_REQUIRELaszlo Ersek2020-03-122-23/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following flash-related base addresses: - PcdFlashNvStorageVariableBase64, - PcdFlashNvStorageFtwWorkingBase, - PcdFlashNvStorageFtwSpareBase, are always set to constant (invariable) values in the "-D SMM_REQUIRE" build of OVMF. (That's because in the SMM build, actual pflash is a hard requirement, and the RAM-based emulation is never available.) Set said PCDs statically, at build. This will allow us to depend on their values in the PEI phase. When SMM_REQUIRE is FALSE, this change has no effect (confirmed by report file comparison). When SMM_REQUIRE is TRUE, the report file shows the following changes: - "PcdOvmfFlashNvStorageFtwSpareBase" and "PcdOvmfFlashNvStorageFtwWorkingBase" are no longer consumed by any module directly, - for "PcdFlashNvStorageFtwSpareBase", "PcdFlashNvStorageFtwWorkingBase" and "PcdFlashNvStorageVariableBase64", the access method changes from DYN to FIXED, - for the latter PCDs, the zero (dynamic default) values are replaced with the desired constants. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-4-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg/QemuFlashFvbServices: factor out SetPcdFlashNvStorageBaseAddressesLaszlo Ersek2020-03-124-18/+60
| | | | | | | | | | | | | | | | | | | | Extract the dynamic setting of the - PcdFlashNvStorageVariableBase64 - PcdFlashNvStorageFtwWorkingBase - PcdFlashNvStorageFtwSpareBase addresses to a helper function. For now, the helper function is identical (duplicated) between the SMM flash driver and the runtime DXE flash driver. In subsequent patches, this will change. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-3-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: drop unused PCDsLaszlo Ersek2020-03-122-4/+0
| | | | | | | | | | | | | | | | | The only two OvmfPkg references to "PcdFlashNvStorageVariableBase" are the spurious ones in the runtime DXE driver and the SMM driver INF files of the QEMU flash driver. Remove these references. The flash driver does not access "PcdOvmfFlashNvStorageEventLogBase" either, so remove that from the INF files too. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-2-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
* OvmfPkg/Qemu: Fix various typosAntoine Coeur2020-02-104-10/+10
| | | | | | | | | | | | | | | | | | | | Fix various typos in comments and documentation. When "VbeShim.asm" is modified, we have to re-run "VbeShim.sh" to update "VbeShim.h". The string modified by this patch is only used when the DEBUG macro (at the top of the file) is commented out. Since the string is not referenced, NASM eliminates it, resulting in the same byte array content in "VbeShim.h". Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-58-philmd@redhat.com>
* OvmfPkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-0911-79/+11
| | | | | | | | | | | | | | | | | | | | 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: Restore C-bit when SEV is activeBrijesh Singh2018-07-062-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>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Do not expose MMIO in SMM buildBrijesh Singh2018-07-064-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>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: mark Flash memory range as MMIOBrijesh Singh2018-07-061-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>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: list "QemuFlash.h" in INF filesLaszlo Ersek2018-03-132-0/+2
| | | | | | | | | | | | | | | | | | | Among other things, the header file declares functions that are called from the FVB protocol member functions in "FwBlockService.c", and defined in "QemuFlash.c". Both C files are listed in both "FvbServicesSmm.inf" and "FvbServicesRuntimeDxe.inf", thus add the header file to both INF files as well. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Michael Kinney <michael.d.kinney@intel.com> Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.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: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: list "FwBlockService.h" in INFsLaszlo Ersek2018-03-132-0/+2
| | | | | | | | | | | | | | | | | | | | | Among other things, the header file provides (extern) declarations for the EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL member functions that are defined in "FwBlockService.c". This way "mFvbDeviceTemplate.FwVolBlockInstance" can be initialized near the top of "FwBlockService.c", ahead of the member function definitions. "FwBlockService.c" is linked into both the DXE_SMM_DRIVER and the DXE_RUNTIME_DRIVER builds of this module, thus list the header file in both INF files. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Michael Kinney <michael.d.kinney@intel.com> Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.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: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Clear C-bit when SEV is activeBrijesh Singh2018-03-095-0/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: correct NumOfLba vararg type in ↵Laszlo Ersek2017-05-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | EraseBlocks() According to the PI spec, Volume 3, EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.EraseBlocks(): > The variable argument list is a list of tuples. Each tuple describes a > range of LBAs to erase and consists of the following: > * An EFI_LBA that indicates the starting LBA > * A UINTN that indicates the number of blocks to erase (NB, in edk2, EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL is a typedef to EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.) In this driver, the NumOfLba local variable is defined with type UINTN, but the TYPE argument passed to VA_ARG() is UINT32. Fix the mismatch. Cc: Jordan Justen <jordan.l.justen@intel.com> Reported-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: eliminate unchecked PcdSetXX() callsLaszlo Ersek2016-10-251-4/+9
| | | | | | | | | | | | | | These are deprecated / disabled under the DISABLE_NEW_DEPRECATED_INTERFACES feature test macro. Introduce a variable called PcdStatus, and use it to assert the success of these operations (there is no reason for them to fail here). Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=166 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: adhere to -D SMM_REQUIRELaszlo Ersek2015-11-305-0/+11
| | | | | | | | | | | | | | 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: add DXE_SMM_DRIVER buildLaszlo Ersek2015-11-302-0/+155
| | | | | | | | 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@19062 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: clean up includes and librariesLaszlo Ersek2015-10-264-26/+13
| | | | | | | | | | | | | | | | | 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-267-131/+209
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: no dual addressing neededLaszlo Ersek2015-10-262-69/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the EFI_FW_VOL_INSTANCE and ESAL_FWB_GLOBAL structures declare the following entries as arrays, with two entries each: - EFI_FW_VOL_INSTANCE.FvBase[2] - ESAL_FWB_GLOBAL.FvInstance[2] In every case, the entry at subscript zero is meant as "physical address", while the entry at subscript one is meant as "virtual address" -- a pointer to the same object. The virtual address entry is originally initialized to the physical address, and then it is converted to the virtual mapping in FvbVirtualddressChangeEvent(). Functions that (a) read the listed fields and (b) run both before and after the virtual address change event -- since this is a runtime DXE driver -- derive the correct array subscript by calling the EfiGoneVirtual() function from UefiRuntimeLib. The problem with the above infrastructure is that it's entirely superfluous. EfiGoneVirtual() "knows" whether EFI has gone virtual only because the UefiRuntimeLib constructor registers the exact same kind of virtual address change callback, and the callback flips a static variabe to TRUE, and EfiGoneVirtual() queries that static variable. In effect this means for QemuFlashFvbServicesRuntimeDxe: "when there is a virtual address change, convert the entries with subscript one from physical to virtual, and from then on use the entries with subscript one". This would only make sense if QemuFlashFvbServicesRuntimeDxe ever needed the original (physical) addresses (ie. the entries with subscript zero) after the virtual address change, but that is not the case. Replace the arrays with single elements. The subscript zero elements simply disappear, and the single elements take the role of the prior subscript one elements. 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@18670 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: remove FvbScratchSpace fieldLaszlo Ersek2015-10-262-3/+0
| | | | | | | | | | | | | | | The ESAL_FWB_GLOBAL.FvbScratchSpace array is never initialized (it contains garbage from AllocateRuntimePool()). Its element at subscript one (=FVB_VIRTUAL), containing garbage as well, is converted to virtual mapping. Then the array is never used again. Remove it. 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@18669 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: remove FvbDevLock fieldLaszlo Ersek2015-10-262-2/+0
| | | | | | | | | | | The EFI_FW_VOL_INSTANCE.FvbDevLock member is initialized and then never used. Remove it. 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@18668 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: fix VALID_ARCHITECTURES in INFLaszlo Ersek2015-10-261-1/+1
| | | | | | | | | | | We build this driver for X64 as well -- the comment isn't overly important, but it shouldn't be misleading. 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@18667 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: QemuFlashFvbServicesRuntimeDxe: rewrap source code to 79 charsLaszlo Ersek2015-10-266-292/+347
| | | | | | | | | | | | | | | | | | | 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: QemuFlashFvbServicesRuntimeDxe: strip trailing whitespaceLaszlo Ersek2015-10-263-19/+19
| | | | | | | | 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@18665 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
* OvmfPg: flash driver: drop gratuitous 64-by-32 bit divisions (VS2010)Laszlo Ersek2014-11-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the InitializeVariableFvHeader() function, all three of "Offset", "Start" and "BlockSize" have type UINTN. Therefore the (Offset / BlockSize) and (Start / BlockSize) divisions can be compiled on all platforms without intrinsics. In the current expressions (EFI_LBA) Offset / BlockSize (EFI_LBA) Start / BlockSize "Offset" and "Start" are cast to UINT64 (== EFI_LBA), which leads to 64-by-32 bit divisions on Ia32, breaking the VS2010 / NOOPT / Ia32 build. The simplest way to fix them is to realize we don't need casts at all. (The prototypes of QemuFlashEraseBlock() and QemuFlashWrite() are visible via "QemuFlash.h", and they will easily take our UINTN quotients as UINT64.) Suggested-by: Scott Duplichan <scott@notabs.org> Contributed-under: TianoCore Contribution Agreement 1.0 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@16383 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPg: flash driver: fix type of EFI_SIZE_TO_PAGES argument (VS2010)Laszlo Ersek2014-11-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MarkMemoryRangeForRuntimeAccess() function passes the Length parameter (of type UINT64) to the macro EFI_SIZE_TO_PAGES(). When building for the Ia32 platform, this violates the interface contract of the macro: [...] Passing in a parameter that is larger than UINTN may produce unexpected results. In addition, it trips up compilation by VS2010 for the Ia32 platform and the NOOPT target -- it generates calls to intrinsics, which are not allowed in edk2. Fix both issues with the following steps: (1) Demote the Length parameter of MarkMemoryRangeForRuntimeAccess() to UINTN. Even a UINT32 value is plenty for representing the size of the flash chip holding the variable store. Length parameter is used in the following contexts: - passed to gDS->RemoveMemorySpace() -- takes an UINT64 - passed to gDS->AddMemorySpace() -- ditto - passed to EFI_SIZE_TO_PAGES() -- requires an UINTN. This also guarantees that the return type of EFI_SIZE_TO_PAGES() will be UINTN, hence we can drop the outer cast. (2) The only caller of MarkMemoryRangeForRuntimeAccess() is FvbInitialize(). The latter function populates the local Length variable (passed to MarkMemoryRangeForRuntimeAccess()) from PcdGet32(PcdOvmfFirmwareFdSize). Therefore we can simply demote the local variable to UINTN in this function as well. - There's only one other use of Length in FvbInitialize(): it is passed to GetFvbInfo(). GetFvbInfo() takes an UINT64, so passing an UINTN is fine. Suggested-by: Scott Duplichan <scott@notabs.org> Contributed-under: TianoCore Contribution Agreement 1.0 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@16382 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Fix VS2005 build warningsJordan Justen2014-09-251-2/+3
| | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16171 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Fix GCC44 build failure.Gao, Liming2014-06-271-0/+1
| | | | | | | | | | Initialize the input parameter FwhInstance in function GetFvbInstance(). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: "Gao, Liming" <liming.gao@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15601 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: add missing braces to aggregate and/or union initializersLaszlo Ersek2014-06-251-9/+13
| | | | | | | | | | | Lack of these braces causes build errors when -Wno-missing-braces is absent. Spelling out more braces also helps understanding the code. 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@15586 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: indicate enablement of flash variables with a dedicated PCDLaszlo Ersek2013-11-122-0/+2
| | | | | | | | | | | | | | | PcdFlashNvStorageVariableBase64 is used to arbitrate between QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, but even the latter driver sets it if we fall back to it. Allow code running later than the startup of these drivers to know about the availability of flash variables, through a dedicated PCD. 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@14843 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add QemuFlashFvbServicesRuntimeDxe driverJordan Justen2013-11-126-0/+1984
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-05-16 08:54:59 +0000