summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: Don't add -mno-mmx -mno-sse option for XCODE5 tool chainLiming Gao2018-04-113-3/+9
| | | | | | | | | | | | | | | Ovmf appended option -mno-mmx -mno-sse, but these two options were enabled in Openssl. The compiler option becomes -mmmx ?msse -mno-mmx -mno-sse. It trig mac clang compiler hang when compile one source file in openssl. This issue is found when SECURE_BOOT_ENABLE is TRUE. This may be the compiler issue. To work around it, don't add these two options for XCODE5 tool chain. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> (cherry picked from commit 4a64cbda8615b9353366df8fc5a0cf3863ac2f11)
* OvmfPkg: Add XCODE5 statements to fix build breakMichael Kinney2017-05-243-0/+6
| | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=559 The XCODE5 tool chain has a FAMILY of GCC. The GCC statements in the [BuildOptions] section add flags that are not compatible with XCODE5. Add empty XCODE5 statements in [BuildOptions] sections to prevent the use of the GCC flags in XCODE5 builds. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Andrew Fish <afish@apple.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> (cherry picked from commit 01e9597540fa418e3db2f853112508be704758bf)
* OvmfPkg: Allow multiple add-pointer linker commands to same ACPI tablePhil Dennis-Jordan2017-03-301-13/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI tables may contain multiple fields which point to the same destination table. For example, in some revisions, the FADT contains both DSDT and X_DSDT fields, and they may both point to the DSDT. Previously, if Qemu created QEMU_LOADER_ADD_POINTER linker commands for such instances, the linking process would attempt to install the same pointed-to table repeatedly. For tables of which there must only be one instance, the call to AcpiProtocol->InstallAcpiTable() would fail during the second linker command pointing to the same table, thus entirely aborting the ACPI table linking process. In the case of tables of which there may be multiple instances, the table would end up duplicated. This change adds a memoisation data structure which tracks the table pointers that have already been processed; even if the same pointer is encountered multiple times, it is only processed once. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: DSDT<->XSDT typo, debug msg, and coding style fixups] Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=368 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/build.sh: Parse qemu version in more casesJordan Justen2017-03-161-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since qemu v2.7.0, the pkgversion appears to have a bug: $ ./configure --target-list=x86_64-softmmu --with-pkgversion=foo Results in this output: $ x86_64-softmmu/qemu-system-x86_64 -version QEMU emulator version 2.8.90(foo) Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers This appears to have been introduced in: 67a1de0d19 Makefile: Derive "PKGVERSION" from "git describe" by default The previous commit (077de81a4c) produces this output: $ x86_64-softmmu/qemu-system-x86_64 -version QEMU emulator version 2.6.50 (foo), Copyright (c) 2003-2008 Fabrice Bellard Now the OvmfPkg/build.sh script uses grep with '-o' to return only the matched text. grep -E is also used with a simple regex to extract only the digits of the version. qemu-bug: https://bugs.launchpad.net/bugs/1673373 Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/QemuFwCfgS3Lib: Fix VS tool chain build failureDandan Bi2017-03-155-16/+17
| | | | | | | | Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/AcpiPlatformDxe: save fw_cfg boot script with QemuFwCfgS3LibLaszlo Ersek2017-03-145-209/+64
| | | | | | | | | | | | | | | | Drop the explicit S3SaveState protocol and opcode management; instead, create ACPI S3 Boot Script opcodes for the WRITE_POINTER commands with QemuFwCfgS3Lib functions. In this case, we have a dynamically allocated Context structure, hence the patch demonstrates how the FW_CFG_BOOT_SCRIPT_CALLBACK_FUNCTION takes ownership of Context. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 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/SmmControl2Dxe: save fw_cfg boot script with QemuFwCfgS3LibLaszlo Ersek2017-03-143-141/+61
| | | | | | | | | | | | | | | | | | | | | | | We cannot entirely eliminate the manual boot script building in this driver, as it also programs lower-level chipset registers (SMI_EN, GEN_PMCON_1) at S3 resume, not just registers exposed via fw_cfg. We can nonetheless replace the manually built opcodes for the latter class of registers with QemuFwCfgS3Lib function calls. We preserve the ordering between the two sets of registers (low-level chipset first, fw_cfg second). This patch demonstrates that manual handling of S3SaveState protocol installation can be combined with QemuFwCfgS3Lib, even without upsetting the original order between boot script fragments. An S3SaveState notify function running at TPL_CALLBACK can safely queue another S3SaveState notify function at TPL_CALLBACK with QemuFwCfgS3CallWhenBootScriptReady(). Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 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/QemuFwCfgS3Lib: implement opcode APIs for DXE fw_cfg instanceLaszlo Ersek2017-03-142-0/+800
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the DXE fw_cfg instance: - QemuFwCfgS3Enabled() queries S3 enablement via fw_cfg. This behavior is shared with the PEI fw_cfg instance, and the DXE fw_cfg instance already pulls in the function from "QemuFwCfgS3PeiDxe.c". - If QemuFwCfgS3Enabled() returns TRUE, the client module is permitted to call QemuFwCfgS3CallWhenBootScriptReady(). We provide a fully functional implementation for QemuFwCfgS3CallWhenBootScriptReady(). A protocol notify is installed at TPL_CALLBACK for EFI_S3_SAVE_STATE_PROTOCOL. If / once the protocol is available, the client module's Callback() function is called, which is expected to produce ACPI S3 Boot Script opcodes using the helper functions listed below. In QemuFwCfgS3CallWhenBootScriptReady(), we also allocate a reserved memory buffer, sized & typed by the client module, for the opcodes and (internally) the fw_cfg DMA operations to work upon, during S3 resume. This behavior is unique to the DXE fw_cfg instance. Thus, add the function to "QemuFwCfgS3Dxe.c". - The QemuFwCfgS3ScriptWriteBytes(), QemuFwCfgS3ScriptReadBytes(), QemuFwCfgS3ScriptSkipBytes(), and QemuFwCfgS3ScriptCheckValue() functions are also implemented usefully, since the client module's Callback() function is expected to invoke them. Each of the first three functions produces MEM_WRITE, IO_WRITE, and MEM_POLL opcodes, to set up the DMA command in reserved memory, to start the DMA transfer, and to check the DMA result, respectively. The QemuFwCfgS3ScriptCheckValue() function produces a MEM_POLL opcode to validate an unsigned integer field in data that was read via QemuFwCfgS3ScriptReadBytes(). This behavior is again unique to the DXE fw_cfg instance, so add the functions to "QemuFwCfgS3Dxe.c". Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 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/QemuFwCfgS3Lib: implement opcode APIs for PEI fw_cfg instanceLaszlo Ersek2017-03-142-0/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the PEI fw_cfg instance: - QemuFwCfgS3Enabled() queries S3 enablement via fw_cfg. This behavior is shared with the DXE fw_cfg instance, and the PEI fw_cfg instance already pulls in the function from "QemuFwCfgS3PeiDxe.c". - If QemuFwCfgS3Enabled() returns TRUE, the client module is permitted to call QemuFwCfgS3CallWhenBootScriptReady(). However, in the PEI phase we have no support for capturing ACPI S3 Boot Script opcodes, hence we return RETURN_UNSUPPORTED unconditionally. This behavior is unique to the PEI fw_cfg instance, so add the function to "QemuFwCfgS3Pei.c". - Consequently, the QemuFwCfgS3ScriptWriteBytes(), QemuFwCfgS3ScriptReadBytes(), QemuFwCfgS3ScriptSkipBytes(), and QemuFwCfgS3ScriptCheckValue() functions must never be called. (They could only be called from the client module's callback, but QemuFwCfgS3CallWhenBootScriptReady() will never install such callback in the PEI fw_cfg instance -- see above.) This behavior is not unique to the PEI fw_cfg instance (it is shared with the Base Null instance), so pull in these functions from "QemuFwCfgS3BasePei.c". Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 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/QemuFwCfgS3Lib: implement opcode APIs for Base Null instanceLaszlo Ersek2017-03-143-0/+302
| | | | | | | | | | | | | | | | | | | | | | | | | | In the Base Null instance: - QemuFwCfgS3Enabled() returns constant FALSE. This is unique to the Base Null instance, and the function is already present in "QemuFwCfgS3Base.c". - The QemuFwCfgS3CallWhenBootScriptReady() function must never be called (according to the documentation, given the above). This is also unique to the Base Null instance, so implement the function in "QemuFwCfgS3Base.c". - Consequently, the QemuFwCfgS3ScriptWriteBytes(), QemuFwCfgS3ScriptReadBytes(), QemuFwCfgS3ScriptSkipBytes(), and QemuFwCfgS3ScriptCheckValue() functions must never be called either. This behavior is not unique to the Base Null instance (it will be shared with the PEI fw_cfg instance), so add these functions to "QemuFwCfgS3BasePei.c". Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 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/QemuFwCfgS3Lib: add boot script opcode generation APIs to libclassLaszlo Ersek2017-03-141-0/+322
| | | | | | | | | | | | | | | | | | | | | | | | Introduce the following APIs: - QemuFwCfgS3CallWhenBootScriptReady(): central function that registers a callback function, with a context parameter, for when ACPI S3 Boot Script opcodes can be produced. This function also allocates reserved memory for the opcodes to operate upon. The client module is supposed to produce the boot script fragment in the callback function. - QemuFwCfgS3ScriptWriteBytes(), QemuFwCfgS3ScriptReadBytes(), QemuFwCfgS3ScriptSkipBytes(), QemuFwCfgS3ScriptCheckValue(): helper functions, available only to the above callback function, for composing the boot script fragment. QemuFwCfgS3ScriptSkipBytes() can double as a plain "select" whenever necessary. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* ArmVirtPkg, OvmfPkg: retire QemuFwCfgS3Enabled() from QemuFwCfgLibLaszlo Ersek2017-03-1413-42/+11
| | | | | | | | | | | | | | | | | | | | At this point we're ready to retire QemuFwCfgS3Enabled() from the QemuFwCfgLib class, together with its implementations in: - ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c - OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c Extend all modules that call the function with a new QemuFwCfgS3Lib class dependency. Thanks to the previously added library class, instances, and class resolutions, we can do this switch now as tightly as possible. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: resolve QemuFwCfgS3LibLaszlo Ersek2017-03-143-0/+9
| | | | | | | | | | | | | | | | | | QemuFwCfgS3Enabled() in "OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c" queries the "etc/system-states" fw_cfg file. The same implementation is now available factored-out in "OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3PeiDxe.c". It is available to PEIMs through the PeiQemuFwCfgS3LibFwCfg instance, and to DXE_DRIVER and DXE_RUNTIME_DRIVER modules through the DxeQemuFwCfgS3LibFwCfg instance. Resolve QemuFwCfgS3Lib accordingly. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 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/QemuFwCfgS3Lib: add initial PEI and DXE fw_cfg library instancesLaszlo Ersek2017-03-143-0/+127
| | | | | | | | | | | | | | | | | | | | This patch introduces PeiQemuFwCfgS3LibFwCfg, a limited functionality QemuFwCfgS3Lib instance, for PEI phase modules. The patch also introduces DxeQemuFwCfgS3LibFwCfg, a full functionality QemuFwCfgS3Lib instance, for DXE_DRIVER and DXE_RUNTIME_DRIVER modules. These library instances share the QemuFwCfgS3Enabled() function. The function actually uses fw_cfg; the implementation is copied from "OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c". The library instances will diverge in the following patches. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 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/QemuFwCfgS3Lib: add initial Base Null library instanceLaszlo Ersek2017-03-142-0/+78
| | | | | | | | | | | | | | | | | This library instance returns constant FALSE from QemuFwCfgS3Enabled(), and all other library functions trigger assertion failures. It is suitable for QEMU targets and machine types that never enable S3. The QemuFwCfgS3Enabled() implementation is copied from "ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c". Stubs for further QemuFwCfgS3Lib APIs (with assertion failures, see above) will be added later. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 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: introduce QemuFwCfgS3Lib classLaszlo Ersek2017-03-142-0/+43
| | | | | | | | | | | | | | | | | | This library class will enable driver modules (a) to query whether S3 support was enabled on the QEMU command line, (b) to produce fw_cfg DMA operations that are to be replayed at S3 resume time. Declare the library class in OvmfPkg/OvmfPkg.dec, and add the library class header under OvmfPkg/Include/Library/. At the moment, the only API we expose is QemuFwCfgS3Enabled(), which we'll first migrate from QemuFwCfgLib. Further interfaces will be added in later patches. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 Suggested-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: exclude libssl functionality from OpensslLib if TLS_ENABLE=FALSELaszlo Ersek2017-02-253-0/+12
| | | | | | | | | | | | | | | The OpensslLibCrypto library instance (which does not contain libssl functions) is sufficient for the Secure Boot feature. Ease security analysis by excluding libssl functionality from the OpensslLib instance we use with TLS_ENABLE=FALSE. Cc: Gary Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com>
* OvmfPkg/XenBusDxe: Use EFIAPI for XenStoreVSPrintAnthony PERARD2017-02-232-0/+2
| | | | | | | | | ... because this function use VA_COPY. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/QemuFwCfg: introduce FW_CFG_IO_DMA_ADDRESS, adapt the packageLaszlo Ersek2017-02-224-5/+6
| | | | | | | | | | | | Introduce the FW_CFG_IO_DMA_ADDRESS macro for IO Ports 0x514 and 0x518 (most significant and least significant halves of the DMA Address Register, respectively), and update all references in OvmfPkg. Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-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/QemuFwCfg: introduce FW_CFG_IO_DATA, adapt the packageLaszlo Ersek2017-02-223-4/+5
| | | | | | | | | | | Introduce the FW_CFG_IO_DATA macro for IO Port 0x511 (the Data Register), and update all references in OvmfPkg. Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-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/QemuFwCfg: introduce FW_CFG_IO_SELECTOR, adapt the packageLaszlo Ersek2017-02-223-2/+8
| | | | | | | | | | | Introduce the FW_CFG_IO_SELECTOR macro for IO Port 0x510 (the Selector Register), and update all references in OvmfPkg. Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-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/QemuFwCfgLib: move types/macros from lib class to IndustryStandardLaszlo Ersek2017-02-222-69/+97
| | | | | | | | Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-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/AcpiPlatformDxe: update PointerValue comments in "BootScript.c"Laszlo Ersek2017-02-221-6/+8
| | | | | | | | | | | | | | | | | | | | Commit df73df138d9d ("OvmfPkg/AcpiPlatformDxe: replay QEMU_LOADER_WRITE_POINTER commands at S3", 2017-02-09) added "BootScript.c" with such comments on the PointerValue field of CONDENSED_WRITE_POINTER, and on the corresponding PointerValue parameter of SaveCondensedWritePointerToS3Context(), that did not consider the then-latest update of the QEMU_LOADER_WRITE_POINTER structure. (Namely, the introduction of the PointeeOffset field.) The code is fine as-is -- ProcessCmdWritePointer() already calls SaveCondensedWritePointerToS3Context() correctly, and "BootScript.c" itself is indifferent to the exact values --, but the comments in "BootScript.c" should match reality too. Update them. Cc: 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/AcpiPlatformDxe: drop double right shift in ADD/WRITE POINTER cmdsLaszlo Ersek2017-02-221-4/+4
| | | | | | | | | | | | | | | | | | | The Count parameter of RShiftU64() must be strictly smaller than 64. ProcessCmdAddPointer() and ProcessCmdWritePointer() currently ensure this by "cleverly" breaking the last bit of a potentially 8-byte right shift out to a separate operation. Instead, exclude the Count==64 case explicitly (in which case the preexistent outer RShiftU64() would return 0), and keep only the inner RShiftU64(), with the direct Count however. This is not a functional change, just style improvement. Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-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/AcpiPlatformDxe: replay QEMU_LOADER_WRITE_POINTER commands at S3Laszlo Ersek2017-02-215-5/+510
| | | | | | | | | | | | | | | | | | | | | | Ultimately, each QEMU_LOADER_WRITE_POINTER command creates a guest memory reference in some QEMU device. When the virtual machine is reset, the device willfully forgets the guest address, since the guest memory is wholly invalidated during platform reset. ... Unless the reset is part of S3 resume. Then the guest memory is preserved intact, and the firmware must reprogram those devices with the original guest memory allocation addresses. This patch accumulates the fw_cfg select, skip and write operations of ProcessCmdWritePointer() in a validated / condensed form, and turns them into an ACPI S3 Boot Script fragment at the very end of InstallQemuFwCfgTables(). Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359 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/AcpiPlatformDxe: implement the QEMU_LOADER_WRITE_POINTER commandLaszlo Ersek2017-02-211-3/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | | The QEMU_LOADER_WRITE_POINTER command instructs the firmware to write the address of a field within a previously allocated/downloaded fw_cfg blob into another (writeable) fw_cfg file at a specific offset. Put differently, QEMU_LOADER_WRITE_POINTER propagates, to QEMU, the address that QEMU_LOADER_ALLOCATE placed the designated fw_cfg blob at, as adjusted for the given field inside the allocated blob. The implementation is similar to that of QEMU_LOADER_ADD_POINTER. Since here we "patch" a pointer object in "fw_cfg file space", not guest memory space, we utilize the QemuFwCfgSkipBytes() and QemuFwCfgWriteBytes() APIs completed in commit range 465663e9f128..7fcb73541299. An interesting aspect is that QEMU_LOADER_WRITE_POINTER creates a host-level reference to a guest memory location. Therefore, if we fail to process the linker/loader script for any reason, we have to clear out those references first, before we release the guest memory allocations in response to the error. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359 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/AcpiPlatformDxe: rewrap license block in "QemuFwCfgAcpi.c"Laszlo Ersek2017-02-211-5/+5
| | | | | | | | | | The longest line is currently 84 characters long. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359 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/AcpiPlatformDxe: add QEMU_LOADER_WRITE_POINTER definitionsLaszlo Ersek2017-02-211-0/+26
| | | | | | | | Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359 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/AcpiPlatformDxe: prepare for QEMU_LOADER_WRITE_POINTER definitionsLaszlo Ersek2017-02-211-5/+5
| | | | | | | | | | | | No functional changes in this patch, just prepare the grounds with some reformatting (trailing comma after the last enumeration constant, horizontal whitespace insertion) so that the next patch can be cleaner. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359 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/IncompatiblePci: Do not use deprecated macrosRuiyu Ni2017-02-101-6/+7
| | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/QemuBootOrderLib: Fix NOOPT build failureDandan Bi2017-02-101-1/+1
| | | | | | | | | | | | | | | | | | | | | This patch is to fix the IA32/NOOPT/VS Toolchain build failure. The VS2015 failure log as below: QemuBootOrderLib.lib(ExtraRootBusMap.obj) : error LNK2001: unresolved external symbol __allmul s:\..\Build\OvmfIa32\NOOPT_VS2015\IA32\MdeModulePkg\ Universal\BdsDxe\BdsDxe\DEBUG\BdsDxe.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 14.0\Vc\bin\link.exe"' : return code '0x460' Stop. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/SmmControl2Dxe: select broadcast SMI if availableLaszlo Ersek2017-02-074-0/+402
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When writing to IO port 0xB2 (ICH9_APM_CNT), QEMU by default injects an SMI only on the VCPU that is writing the port. This has exposed corner cases and strange behavior with edk2 code, which generally expects a software SMI to affect all CPUs at once. We've experienced instability despite the fact that OVMF sets PcdCpuSmmApSyncTimeout and PcdCpuSmmSyncMode differently from the UefiCpuPkg defaults, such that they match QEMU's unicast SMIs better. (Refer to edk2 commits 9b1e378811ff and bb0f18b0bce6.) Using the new fw_cfg-based SMI feature negotiation in QEMU (see commits 50de920b372b "hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg" and 5ce45c7a2b15 "hw/isa/lpc_ich9: add broadcast SMI feature"), we can ask QEMU to broadcast SMIs. Extensive testing from earlier proves that broadcast SMIs are only reliable if we use the UefiCpuPkg defaults for the above PCDs. With those settings however, the broadcast is very reliable -- the most reliable configuration encountered thus far. Therefore negotiate broadcast SMIs with QEMU, and if the negotiation is successful, dynamically revert the PCDs to the UefiCpuPkg defaults. Setting the PCDs in this module is safe: - only PiSmmCpuDxeSmm consumes them, - PiSmmCpuDxeSmm is a DXE_SMM_DRIVER, launched by the SMM_CORE (MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf), - the SMM_CORE is launched by the SMM IPL runtime DXE driver (MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf), - the SMM IPL has a DEPEX on EFI_SMM_CONTROL2_PROTOCOL, - OvmfPkg/SmmControl2Dxe produces that protocol. The end result is that PiSmmCpuDxeSmm cannot be dispatched before SmmControl2Dxe installs EFI_SMM_CONTROL2_PROTOCOL and returns from its entry point. Hence we can set the PCD's consumed by PiSmmCpuDxeSmm in SmmControl2Dxe. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=230 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: dynamic defaults for PcdCpuSmmApSyncTimeout, PcdCpuSmmSyncModeLaszlo Ersek2017-02-073-6/+15
| | | | | | | | | | | | Move the platform-specific default values for these PCDs from the [PcdsFixedAtBuild] / [PcdsFixedAtBuild.X64] sections to the [PcdsDynamicDefault] section. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=230 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/QemuFwCfgLib: add QemuFwCfgSkipBytes()Laszlo Ersek2017-01-312-0/+60
| | | | | | | | | | | | | | | | | | | | | Introduce the new public API QemuFwCfgSkipBytes(), for advancing over bytes in the selected firmware configuration item without transferring data between the item and the caller. When the DMA interface is available (the common case), the operation is instantaneous. As a fallback, provide a loop of chunked reads into a small stack-allocated scratch buffer. This patch enables OvmfPkg/QemuFwCfgLib to overwrite part of a writeable fw_cfg file, which will be particularly useful for the upcoming QEMU_LOADER_WRITE_POINTER command in OvmfPkg/AcpiPlatformDxe. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359 Contributed-under: TianoCore Contribution Agreement 1.0 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/QemuFwCfgLib: generalize InternalQemuFwCfgDmaBytes() to SKIP opLaszlo Ersek2017-01-311-12/+19
| | | | | | | | | | | | | | The fw_cfg DMA interface provides a simple method to skip over bytes in an fw_cfg blob before reading or writing more bytes. InternalQemuFwCfgDmaBytes() can support it easily, we just have to expose the Control parameter more flexibly than the current "Write" BOOLEAN. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359 Contributed-under: TianoCore Contribution Agreement 1.0 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/QemuVideoDxe: Frame buffer config size may change in new modeRuiyu Ni2017-01-241-21/+26
| | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=339 The patch removes the assumption in QemuVideoDxe driver that it wrongly assumes the frame buffer configure size is the same in different video modes. The assumption is true in old FrameBufferBltLib but is false in new implementation. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Allow HTTP connections if HTTP Boot enabledJiaxin Wu2017-01-233-3/+15
| | | | | | | | | | | | | | | | | | | | | | v2 * Move the setting above the "!ifndef $(USE_OLD_SHELL)" part. * Un-indent the setting to column zero. (Comments from Laszlo) Overwrite the value of PcdAllowHttpConnections to allow HTTP connections if HTTP Boot enabled (-D HTTP_BOOT_ENABLE). Cc: Laszlo Ersek <lersek@redhat.com> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Kinney Michael D <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com>
* OvmfPkg: Remove superfluous return statements.Thomas Huth2017-01-192-6/+0
| | | | | | | | | If the code eventually returns "Status" anyway, it does not make sense to explicitely return "Status" in case of an error, too. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: pull in TLS modules with -D TLS_ENABLE (also enabling HTTPS)Gary Lin2017-01-176-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | This commit introduces a new build option, TLS_ENABLE, to pull in the TLS-related modules. If HTTP_BOOT_ENABLE and TLS_ENABLE are enabled at the same time, the HTTP driver locates the TLS protocols automatically and thus HTTPS is enabled. To build OVMF with HTTP Boot: $ ./build.sh -D HTTP_BOOT_ENABLE To build OVMF with HTTPS Boot: $ ./build.sh -D HTTP_BOOT_ENABLE -D TLS_ENABLE Cc: Laszlo Ersek <lersek@redhat.com> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Long Qin <qin.long@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: correct the IScsiDxe module included for the IPv6 stackGary Lin2017-01-176-33/+12
| | | | | | | | | | | | | | | | | | | | | Always use IScsiDxe from NetworkPkg when IPv6 is enabled since it provides the complete ISCSI support. NOTE: This makes OpenSSL a hard requirement when NETWORK_IP6_ENABLE is true. (Based on Jiaxin's suggestion) Cc: Laszlo Ersek <lersek@redhat.com> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Long Qin <qin.long@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: update subject line] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: always resolve OpenSslLib, IntrinsicLib and BaseCryptLibGary Lin2017-01-173-18/+9
| | | | | | | | | | | | | | | | | | | | | This commit provides unconditional library resolutions for the OpenSslLib, IntrinsicLib and BaseCryptLib classes, regardless of whether those classes are actually used by any module. Although those libraries depends on OpenSSL, they won't be built unless a module really uses them. Thus, missing OpenSSL from the tree won't cause any build failure as long as SECURE_BOOT_ENABLE is false. (Based on Jiaxin's patch and Laszlo's suggestion) Cc: Laszlo Ersek <lersek@redhat.com> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Long Qin <qin.long@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Modify QemuFwCfgLib to use new IoLib class libraryLeo Duran2017-01-175-172/+3
| | | | | | | | | | | | | The Fifo routines from the QuemuFwCfgLib library have been ported to the new BaseIoLibIntrinsic (IoLib class) library. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Leo Duran <leo.duran@amd.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmgPkg/PlatformBootManagerLib: Add Debug Agent consoleMichael Kinney2017-01-103-3/+67
| | | | | | | | | | | | | | | | | | | | | | The Debug Agent in the SourceLevelDebugPkg can multiplex both source level debug messages and console messages on the same UART. When this is done, the Debug Agent owns the UART device and an additional device handle with a Serial I/O Protocol is produced with a VenHw device path node. In order for a platform to provide a UART based console when the Debug Agent is using the same UART device, the PlatformBootManagerLib must consider the SerialI/O Protocol produces by the Debug Agent as one of the supported consoles. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jeff Fan <jeff.fan@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/SmmControl2Dxe: correct PCI_CONFIG_READ_WRITE in S3 boot scriptLaszlo Ersek2017-01-092-1/+10
| | | | | | | | | | | | | | | EFI_BOOT_SCRIPT_PCI_CONFIG_READ_WRITE_OPCODE expects the PCI address to access in UEFI encoding, not in edk2/PciLib encoding. Introduce the POWER_MGMT_REGISTER_Q35_EFI_PCI_ADDRESS() macro, and with it, store the ICH9_GEN_PMCON_1 register's address to the boot script in UEFI representation. Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: 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: Install BGRT ACPI tableBhupesh Sharma2017-01-066-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While debugging OS for ACPI BGRT support (especially on VMs), it is very useful to have the EFI firmware (OVMF in most cases which use Tianocore) to export the ACPI BGRT table. This patch tries to add this support in OvmfPkg. Tested this patch in the following environments: 1. On both RHEL7.3 and Fedora-25 VM guests running on a Fedora-24 Host: - Ensured that the BGRT logo is properly prepared and can be viewed with user-space tools (like 'Gwenview' on KDE, for example): $ file /sys/firmware/acpi/bgrt/image /sys/firmware/acpi/bgrt/image: PC bitmap, Windows 3.x format, 193 x 58 x 24 2. On a Windows-10 VM Guest running on a Fedora-24 Host: - Ensured that the BGRT ACPI table is properly prepared and can be read with freeware tool like FirmwareTablesView: ================================================== Signature : BGRT Firmware Provider : ACPI Length : 56 Revision : 1 Checksum : 129 OEM ID : INTEL OEM Table ID : EDK2 OEM Revision : 0x00000002 Creator ID : 0x20202020 Creator Revision : 0x01000013 Description : ================================================== Note from Laszlo Ersek <lersek@redhat.com>: without the BGRT ACPI table, Windows 8 and Windows 10 first clear the screen, then display a blue, slanted Windows picture above the rotating white boot animation. With the BGRT ACPI table, Windows 8 and Windows 10 don't clear the screen, the blue Windows image is not displayed, and the rotating white boot animation is shown between the firmware's original TianoCore boot splash and (optional) "Start boot option" progress bar. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: cover effect on Windows 8/10 boot anim. in commit msg] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/build.sh: Use GCC49 toolchains with GCC 6.[0-2]Anthony PERARD2016-12-061-1/+1
| | | | | | | | | | | | The goal of the patch is to avoid using -flto with GCC 6.0 to 6.2. This is to workaround a GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/XenHypercallLib: Add EFIAPIAnthony PERARD2016-12-062-0/+6
| | | | | | | | | | Because EFIAPI is necessary for functions declared in library class header files. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/QemuFwCfgLib: support QEMU's DMA-like fw_cfg access methodLaszlo Ersek2016-12-054-1/+124
| | | | | | | | | | | | | | | | | | | | | The benefits of the DMA-like access method are (a) speed, (b) write support in QEMU 2.9+. (IOPort-based write support was discontinued in QEMU 2.4, and the DMA-based one is being added to QEMU 2.9. Write support needs no separate feature detection because writeability is governed on the level of individual fw_cfg files -- if a file meant to be written by the firmware exists in the directory, then it is writeable with the DMA method.) We don't enable this feature for the SEC library instance, because: - the SEC instance remains without clients (I've checked that it builds though), - in SEC, any possible fw_cfg use is expected to be small and read-only. Cc: 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/QemuFwCfgLib: extend lib class header with more definitionsLaszlo Ersek2016-12-051-0/+8
| | | | | | | | | | | | | | The last patch consists purely of code movement; going forward, we should use a few more symbolic constants. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* ArmVirtPkg, OvmfPkg: QemuFwCfgLib: move DMA-related defs to lib classLaszlo Ersek2016-12-051-0/+19
| | | | | | | | | | | | | | Move the type and macro definitions related to QEMU's DMA-like fw_cfg access method to the library class header. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-15 03:09:03 +0000