summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/AcpiPlatformDxe
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: replace old EFI_D_ debug levels with new DEBUG_ onesRebecca Cran2020-04-303-34/+34
| | | | | | | | | | | | | 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/Qemu: Fix various typosAntoine Coeur2020-02-102-3/+3
| | | | | | | | | | | | | | | | | | | | 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/Acpi: Fix few typosAntoine Coeur2020-02-101-1/+1
| | | | | | | | | | | | | Fix few typos in comments and documentation. 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-55-philmd@redhat.com>
* OvmfPkg: strip trailing whitespaceLeif Lindholm2019-10-042-6/+6
| | | | | | | | | | | | | Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@arm.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it existAnthony PERARD2019-08-211-0/+17
| | | | | | | | | | If the firmware have been started via the Xen PVH entry point, a RSDP pointer would have been provided. Use it. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-16-anthony.perard@citrix.com>
* OvmfPkg/AcpiPlatformDxe: Use XenPlatformLibAnthony PERARD2019-08-213-31/+2
| | | | | | | | | | This patch replace the XenDetected() function by the one in XenPlatformLib. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-15-anthony.perard@citrix.com>
* OvmfPkg/AcpiPlatformDxe: catch theoretical nullptr deref in Xen codeLaszlo Ersek2019-04-181-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RH covscan justifiedly reports a path through InstallXenTables() where DsdtTable can technically remain NULL. If this occurs in practice, then the guest and the VMM are out of sync on the interface contract. Catch the situation with a code snippet that halts in RELEASE builds, and in DEBUG builds lets the platform DSC control the assert disposition first (i.e. CPU exception, deadloop, or nothing). > Error: CLANG_WARNING: > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/Xen.c:309:14: warning: Access > to field 'Length' results in a dereference of a null pointer (loaded > from variable 'DsdtTable') > # DsdtTable->Length, > # ^~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/Xen.c:154:3: note: Null > pointer value stored to 'DsdtTable' > # DsdtTable = NULL; > # ^~~~~~~~~~~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/Xen.c:162:3: note: Taking > false branch > # if (EFI_ERROR (Status)) { > # ^ > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/Xen.c:170:7: note: Assuming > the condition is false > # if (XenAcpiRsdpStructurePtr->XsdtAddress) { > # ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/Xen.c:170:3: note: Taking > false branch > # if (XenAcpiRsdpStructurePtr->XsdtAddress) { > # ^ > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/Xen.c:220:12: note: Assuming > the condition is false > # else if (XenAcpiRsdpStructurePtr->RsdtAddress) { > # ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/Xen.c:220:8: note: Taking > false branch > # else if (XenAcpiRsdpStructurePtr->RsdtAddress) { > # ^ > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/Xen.c:274:3: note: Taking > false branch > # if (Fadt2Table) { > # ^ > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/Xen.c:288:8: note: Taking > false branch > # else if (Fadt1Table) { > # ^ > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/Xen.c:309:14: note: Access to > field 'Length' results in a dereference of a null pointer (loaded from > variable 'DsdtTable') > # DsdtTable->Length, > # ^~~~~~~~~ > # 307| AcpiProtocol, > # 308| DsdtTable, > # 309|-> DsdtTable->Length, > # 310| &TableHandle > # 311| ); Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710 Issue: scan-0993.txt Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/AcpiPlatformDxe: suppress invalid "deref of undef pointer" warningLaszlo Ersek2019-04-181-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RH covscan emits the following false positive: > Error: CLANG_WARNING: > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c:182:14: > warning: Dereference of undefined pointer value > # Status = FwVol->ReadSection ( > # ^~~~~~~~~~~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c:164:7: note: > Assuming the condition is false > # if (QemuDetected ()) { > # ^~~~~~~~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c:164:3: note: > Taking false branch > # if (QemuDetected ()) { > # ^ > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c:174:3: note: > Taking false branch > # if (EFI_ERROR (Status)) { > # ^ > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c:180:10: note: > Assuming 'Status' is equal to EFI_SUCCESS > # while (Status == EFI_SUCCESS) { > # ^~~~~~~~~~~~~~~~~~~~~ > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c:180:3: note: > Loop condition is true. Entering loop body > # while (Status == EFI_SUCCESS) { > # ^ > edk2-89910a39dcfd/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c:182:14: note: > Dereference of undefined pointer value > # Status = FwVol->ReadSection ( > # ^~~~~~~~~~~~~~~~~~ > # 180| while (Status == EFI_SUCCESS) { > # 181| > # 182|-> Status = FwVol->ReadSection ( > # 183| FwVol, > # 184| (EFI_GUID*)PcdGetPtr (PcdAcpiTableStorageFile), This is invalid because LocateFvInstanceWithTables() sets FwVol on success. Suppress the message by: - assigning FwVol NULL first (this would replace the original report with "nullptr deref"), - asserting that FwVol is no longer NULL, on success. What's important here is that ASSERT() ends with ANALYZER_UNREACHABLE() on failure. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710 Issue: scan-0991.txt Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/AcpiPlatformDxe: Consume the 8259 PCD defined in OvmfPkgHao Wu2019-04-111-3/+2
| | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496 Several updates have been made to the OvmfPkg/AcpiPlatformDxe driver to drop its dependency on PcAtChipsetPkg: A) Consumes the PCD 'Pcd8259LegacyModeEdgeLevel' defined within OvmfPkg; B) Remove the PcAtChipsetPkg DEC file dependency in the driver INF file. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-0912-84/+12
| | | | | | | | | | | | | | | | | | | | 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/AcpiPlatformDxe: clean up libs and protos in "AcpiPlatformDxe.inf"Laszlo Ersek2018-07-191-1/+1
| | | | | | | | | | | | | | | | | | | | | None of the source files referenced by "AcpiPlatformDxe.inf" #include "MdePkg/Include/Library/DxeServicesLib.h" or use interfaces declared therein, so drop DxeServicesLib from [LibraryClasses]. "AcpiPlatformDxe.inf" references "AcpiPlatform.c", which installs ACPI tables built into the firmware image from under "OvmfPkg/AcpiTables/", in case dynamically generated ACPI tables are not available from Xen or QEMU. For this, the driver consumes gEfiFirmwareVolume2ProtocolGuid. Account for that in [Protocols]. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Steven Shi <steven.shi@intel.com> Reported-by: Steven Shi <steven.shi@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1014 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: Removing ipf which is no longer supported from edk2.chenc22018-06-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removing rules for Ipf sources file: * Remove the source file which path with "ipf" and also listed in [Sources.IPF] section of INF file. * Remove the source file which listed in [Components.IPF] section of DSC file and not listed in any other [Components] section. * Remove the embedded Ipf code for MDE_CPU_IPF. Removing rules for Inf file: * Remove IPF from VALID_ARCHITECTURES comments. * Remove DXE_SAL_DRIVER from LIBRARY_CLASS in [Defines] section. * Remove the INF which only listed in [Components.IPF] section in DSC. * Remove statements from [BuildOptions] that provide IPF specific flags. * Remove any IPF sepcific sections. Removing rules for Dec file: * Remove [Includes.IPF] section from Dec. Removing rules for Dsc file: * Remove IPF from SUPPORTED_ARCHITECTURES in [Defines] section of DSC. * Remove any IPF specific sections. * Remove statements from [BuildOptions] that provide IPF specific flags. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Chen A Chen <chen.a.chen@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/AcpiPlatformDxe: list "QemuLoader.h" in the INF filesLaszlo Ersek2018-03-132-0/+2
| | | | | | | | | | | | | | | | | | "QemuLoader.h" defines the command structures of QEMU's ACPI linker/loader. The client code is in "QemuFwCfgAcpi.c", which is part of both builds of this driver. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Phil Dennis-Jordan <phil@philjordan.eu> 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/AcpiPlatformDxe: don't #include "QemuLoader.h" in "Qemu.c"Laszlo Ersek2018-03-131-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | We added initial support for QEMU's ACPI linker/loader in commit a618eaa1f45d ("OvmfPkg: AcpiPlatformDxe: don't rely on unstable QEMU interface", 2014-06-19). This commit defined the command structures in the new file "QemuLoader.h", and #included the header in the preexistent "Qemu.c" file, where the initial command script processing loop was being implemented. In commit 14b0faadfc87 ("OvmfPkg/AcpiPlatformDxe: Split QEMU fw-cfg into a new file", 2015-02-02), we extracted the -- by then, more advanced -- linker/loader script processing from "Qemu.c" to "QemuFwCfgAcpi.c". "Qemu.c" was going to need "QemuLoader.h" no longer, but we forgot to make the #include directive unique to the new "QemuFwCfgAcpi.c" file. Do it now. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Phil Dennis-Jordan <phil@philjordan.eu> 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/AcpiPlatformDxe: list "AcpiPlatform.h" in the INF filesLaszlo Ersek2018-03-132-0/+2
| | | | | | | | | | | | | | | | | | | | Among other things, the header file declares InstallAcpiTables(). This function is called from AcpiPlatformEntryPoint() -- the entry point of both INF files, defined in the common "EntryPoint.c" file --, and it is defined (dependent on INF file) in "AcpiPlatform.c" or "QemuFwCfgAcpiPlatform.c". Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Phil Dennis-Jordan <phil@philjordan.eu> 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/AcpiPlatformDxe: sort [Sources*] sections in the INF filesLaszlo Ersek2018-03-132-6/+6
| | | | | | | | | | | | | | | This makes it easier to insert future source files, and to see the source files that are unique to either INF file. No functional changes. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Phil Dennis-Jordan <phil@philjordan.eu> 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/AcpiPlatformDxe: short-circuit the transfer of an empty S3_CONTEXTLaszlo Ersek2017-08-081-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 805762252733 ("OvmfPkg/AcpiPlatformDxe: save fw_cfg boot script with QemuFwCfgS3Lib", 2017-02-23), we replaced the explicit S3 boot script manipulation in TransferS3ContextToBootScript() with a call to QemuFwCfgS3CallWhenBootScriptReady(). (Passing AppendFwCfgBootScript() as callback.) QemuFwCfgS3CallWhenBootScriptReady() checks for fw_cfg DMA up-front, and bails with RETURN_NOT_FOUND if fw_cfg DMA is missing. (This is justified as the goal of QemuFwCfgS3Lib is to "enable[] driver modules [...] to produce fw_cfg DMA operations that are to be replayed at S3 resume time".) In turn, if QemuFwCfgS3CallWhenBootScriptReady() fails, then OvmfPkg/AcpiPlatformDxe rolls back any earlier linker/loader script processing, and falls back to the built-in ACPI tables. (This is also justified because failure to save WRITE_POINTER commands for replaying at S3 resume implies failure to process the linker/loader script comprehensively.) Calling QemuFwCfgS3CallWhenBootScriptReady() from TransferS3ContextToBootScript() *unconditionally* is wrong however. For the case when the linker/loader script contains no WRITE_POINTER commands, the call perpetuated an earlier side effect, and introduced another one: (1) On machine types that provide fw_cfg DMA (i.e., 2.5+), QemuFwCfgS3CallWhenBootScriptReady() would succeed, and allocate workspace for the boot script opcodes in reserved memory. However, no opcodes would actually be produced in the AppendFwCfgBootScript() callback, due to lack of any WRITE_POINTER commands. This waste of reserved memory had been introduced in earlier commit df73df138d9d ("OvmfPkg/AcpiPlatformDxe: replay QEMU_LOADER_WRITE_POINTER commands at S3", 2017-02-09). (2) On machine types that lack fw_cfg DMA (i.e., 2.4 and earlier), TransferS3ContextToBootScript() would now fail the linker/loader script for no reason. (Note that QEMU itself prevents adding devices that depend on WRITE_POINTER if the machine type lacks fw_cfg DMA: $ qemu-system-x86_64 -M pc-q35-2.4 -device vmgenid qemu-system-x86_64: -device vmgenid: vmgenid requires DMA write support in fw_cfg, which this machine type does not provide) Short-circuit an empty S3_CONTEXT in TransferS3ContextToBootScript() by dropping S3_CONTEXT on the floor. This is compatible with the current contract of the function as it constitutes a transfer of ownership. Regression (2) was found and reported by Dhiru Kholia as an OSX guest boot failure on the "pc-q35-2.4" machine type: http://mid.mail-archive.com/CANO7a6x6EaWNZ8y=MvLU=w_LjRLXserO3NmsgHvaYE0aUCCWzg@mail.gmail.com Dhiru bisected the issue to commit 805762252733. Cc: Dhiru Kholia <dhiru.kholia@gmail.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: df73df138d9d53f7f7570f4fe97a6cde941a2656 Fixes: 805762252733bb67bc5157f0137c64e010724c77 Reported-by: Dhiru Kholia <dhiru.kholia@gmail.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Dhiru Kholia <dhiru.kholia@gmail.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/AcpiPlatformDxe: fix spurious uninitialized var warningArd Biesheuvel2017-06-091-0/+1
| | | | | | | | | | | Commit 4275f38507a4 ("OvmfPkg/AcpiPlatformDxe: alloc blobs from 64-bit space unless restricted") introduced a variable which is [incorrectly] identified by GCC as being potentially uninitialized. So let's just set it to NULL before use. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/AcpiPlatformDxe: alloc blobs from 64-bit space unless restrictedLaszlo Ersek2017-06-081-7/+190
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... by narrower than 8-byte ADD_POINTER references. Introduce the CollectAllocationsRestrictedTo32Bit() function, which iterates over the linker/loader script, and collects the names of the fw_cfg blobs that are referenced by QEMU_LOADER_ADD_POINTER.PointeeFile fields, such that QEMU_LOADER_ADD_POINTER.PointerSize is less than 8. This means that the pointee blob's address will have to be patched into a narrower-than-8 byte pointer field, hence the pointee blob must not be allocated from 64-bit address space. In ProcessCmdAllocate(), consult these restrictions when setting the maximum address for gBS->AllocatePages(). The default is now MAX_UINT64, unless restricted like described above to the pre-patch MAX_UINT32 limit. In combination with Ard's QEMU commit cb51ac2ffe36 ("hw/arm/virt: generate 64-bit addressable ACPI objects", 2017-04-10), this patch enables OvmfPkg/AcpiPlatformDxe to work entirely above the 4GB mark. (An upcoming / planned aarch64 QEMU machine type will have no RAM under 4GB at all. Plus, moving the allocations higher is beneficial to the current "virt" machine type as well; in Ard's words: "having all firmware allocations inside the same 1 GB (or 512 MB for 64k pages) frame reduces the TLB footprint".) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Igor Mammedov <imammedo@redhat.com> Suggested-by: Gerd Hoffmann <kraxel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* 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/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>
* ArmVirtPkg, OvmfPkg: retire QemuFwCfgS3Enabled() from QemuFwCfgLibLaszlo Ersek2017-03-143-0/+3
| | | | | | | | | | | | | | | | | | | | 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/QemuFwCfg: introduce FW_CFG_IO_DMA_ADDRESS, adapt the packageLaszlo Ersek2017-02-221-2/+2
| | | | | | | | | | | | 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/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: Fix typing errorsThomas Huth2016-09-121-1/+1
| | | | | | | | | | | Correct some typos (discovered with the codespell utility) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Thomas Huth <thuth@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: AcpiPlatformDxe: Don't enable unsupported PCI attributesVolker Rümelin2016-04-191-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current code in PciEnableDecoding tries to unconditionally enable EFI_PCI_IO_ATTRIBUTE_IO and EFI_PCI_IO_ATTRIBUTE_MEMORY even if they are unsupported attributes. This fails on devices which don't support both attributes. This patch masks out unsupported attributes. Information to reproduce the bug. Host lspci -s 0000:04:00.0 -vnn: 04:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller [1912:0014] (rev 03) (prog-if 30 [XHCI]) Flags: fast devsel, IRQ 19 Memory at ef900000 (64-bit, non-prefetchable) [size=8K] Capabilities: [50] Power Management version 3 Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+ Capabilities: [90] MSI-X: Enable- Count=8 Masked- Capabilities: [a0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [150] Latency Tolerance Reporting Kernel driver in use: pci-stub Kernel modules: xhci_pci libvirt xml: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x04' slot='0x00' function='0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x11' function='0'/> </hostdev> OVMF debug log with additional DEBUG statement: OnRootBridgesConnected: root bridges have been connected, installing ACPI tables Select Item: 0x19 EnablePciDecoding: GetLocation: D=0000:00:00.0 OrigAttr=0000000000004000 SuppAttr=000000000000E700 EnablePciDecoding: GetLocation: D=0000:00:10.0 OrigAttr=0000000000004000 SuppAttr=000000000000E700 EnablePciDecoding: GetLocation: D=0000:00:11.0 OrigAttr=0000000000004000 SuppAttr=000000000000E600 EnablePciDecoding: EfiPciIoAttributeOperationEnable: Unsupported Select Item: 0x28 Select Item: 0x19 Select Item: 0x2A Select Item: 0x19 Select Item: 0x27 InstallQemuFwCfgTables: installed 6 tables Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: AcpiPlatformDxe: enable PCI IO and MMIO while fetching QEMU tablesLaszlo Ersek2016-03-235-0/+212
| | | | | | | | | | | | | | | | | | | | | Now that the previous patches ensure that we can access all PCI devices in AcpiPlatformDxe, we can enable IO and MMIO decoding for all of them while we contact QEMU for the ACPI tables. See more details in the patch titled: OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid In particular, this patch will prevent the bug when the 64-bit MMIO aperture is completely missing from QEMU's _CRS, and consequently Linux rejects 64-bit BARs with the error message pci 0000:00:03.0: can't claim BAR 4 [mem 0x800000000-0x8007fffff 64bit pref]: no compatible bridge window Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> 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: when PCI is enabled, wait for Platform BDS's cueLaszlo Ersek2016-03-233-36/+18
| | | | | | | | | | | | | | | | | | | | | | | | This patch doesn't change the behavior of AcpiPlatformDxe when PcdPciDisableBusEnumeration is TRUE -- that is, when the driver runs on Xen (OvmfPkg and ArmVirtPkg both), or when the driver runs on QEMU as part of ArmVirtPkg but no PCI host bridge was found by VirtFdtDxe. In these cases the driver continues to install the ACPI tables immediately. However, when PcdPciDisableBusEnumeration is FALSE (i.e., when the driver runs on QEMU as part of OVMF, or as part of ArmVirtPkg and VirtFdtDxe finds a PCI host bridge), we now delay the ACPI table download from QEMU. We wait until the Platform BDS tells us that root bridges have been connected, and PciIo instances are available. The explanation is in the patch titled OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> 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: make dependency on PCI enumeration dynamicLaszlo Ersek2015-02-193-6/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SVN r16411 delayed ACPI table installation until PCI enumeration was complete, because on QEMU the ACPI-related fw_cfg files should have been downloaded only after PCI enumeration. Said commit implemented the dependency by tightening the module's depex. This patch replaces the EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL depex with a matching protocol registration callback. The depex was static, and it could not handle dynamically discovered situations when the dependency would turn out invalid. Namely: - At the moment, the depex in "QemuFwCfgAcpiPlatformDxe.inf" assumes that "ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc" lacks PCI support. However, PCI support is about to become run-time discoverable on that platform. If PCI support is missing, then ArmVirtualizationPkg will set PcdPciDisableBusEnumeration to TRUE. Hence, when PcdPciDisableBusEnumeration is TRUE, we invalidate the dependency by not registering the callback and installing the ACPI tables right away. - InitializeXen() in "OvmfPkg/PlatformPei/Xen.c" sets PcdPciDisableBusEnumeration to TRUE. This causes PciBusDriverBindingStart() in "MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c" to set gFullEnumeration to FALSE, which in turn makes PciEnumerator() in "MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c" branch to PciEnumeratorLight(). The installation of EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL at the end of PciEnumerator() is not reached. Which means that starting with SVN r16411, AcpiPlatformDxe is never dispatched on Xen. Hence, when PcdPciDisableBusEnumeration is TRUE, we invalidate the dependency by not registering the callback and installing the ACPI tables right away. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [jordan.l.justen@intel.com: Removed PcdOvmfPciEnabled] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16887 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: AcpiPlatformDxe: extract common entry pointLaszlo Ersek2015-02-197-52/+99
| | | | | | | | | | | | | | | | | | | | | | | | Currently the entry point functions of both driver builds (AcpiPlatformDxe.inf and QemuFwCfgAcpiPlatformDxe.inf) directly contain the logic that is different between the two builds. Because we're going to restructure the entry point logic soon, we'd have to duplicate the same new code between both entry point functions. Push down the logic in which they differ to a new function: - InstallAcpiTables() [AcpiPlatform.c] - InstallAcpiTables() [QemuFwCfgAcpiPlatform.c] and extract a common entry point function: - AcpiPlatformEntryPoint() [EntryPoint.c] which we can soon modify without code duplication. 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@16885 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe: InstallAllQemuLinkedTables => InstallQemuFwCfgTablesJordan Justen2015-02-193-4/+5
| | | | | | | | | | This name better aligns with InstallXenTables and InstallOvmfFvTables. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16884 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe: FindAcpiTablesInFv => InstallOvmfFvTablesJordan Justen2015-02-191-3/+9
| | | | | | | | | | | Since this function also installs the tables, this is a better name. It also aligns with the InstallXenTables name. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16883 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe: Assert if AcpiTable protocol is not foundJordan Justen2015-02-172-6/+2
| | | | | | | | | | | Since the protocol is in the depex, there is no reason to expect we might fail to locate the protocol. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16882 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/QemuFwCfgAcpiPlatformDxe: Move entry point to QemuFwCfgAcpi.cJordan Justen2015-02-173-53/+38
| | | | | | | | | | | Having this entry point in QemuFwCfgAcpi.c should not cause a problem for the other driver which supports Xen and older QEMU versions. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16880 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe: Add QEMU fw-cfg only driverJordan Justen2015-02-022-0/+105
| | | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16697 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe: Split QEMU fw-cfg into a new fileJordan Justen2015-02-023-660/+686
| | | | | | | | | | | | The code left behind in Qemu.c has some PCAT dependencies, and might not be able to build on all platforms. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16696 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: AcpiPlatformDxe: make dependency on PCI enumeration explicitLaszlo Ersek2014-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI payload that OVMF downloads from QEMU via fw_cfg depends on the PCI enumaration and resource assignment performed by MdeModulePkg/Bus/Pci/PciBusDxe. Namely, although the ACPI payload is pre-generated in qemu during machine initialization, in main() [vl.c] qemu_run_machine_init_done_notifiers() pc_guest_info_machine_done() [hw/i386/pc.c] acpi_setup() [hw/i386/acpi-build.c] acpi_build() acpi_add_rom_blob() rom_add_blob(... acpi_build_update ...) [hw/core/loader.c] fw_cfg_add_file_callback() [hw/nvram/fw_cfg.c] the ACPI data is rebuilt at the first time any of the related fw_cfg files are read, through the acpi_build_update() fw_cfg read-callback function: fw_cfg_read() [hw/nvram/fw_cfg.c] acpi_build_update() [hw/i386/acpi-build.c] acpi_build() (See qemu commit d87072ceeccf4f84a64d4bc59124bcd64286c070 and its containing series.) For this reason we must not dispatch AcpiPlatformDxe before PciBusDxe completes the enumeration. Luckily, the PI Specification 1.3 defines EFI_PCI_ENUMERATION_COMPLETE_GUID in Volume 5, "10.9 End of PCI Enumeration Overview", as an indicia to inform the platform when the PCI enumeration process has completed. PciBusDxe installs this protocol at the end of the PciEnumerator() function. Let's add this GUID to the Depex section of AcpiPlatformDxe, in order to state the dependency explicitly. On Xen, and on older QEMU where the linker/loader fw_cfg interface is unavailable, this introduces a harmless ordering constraint -- we'll always include PciBusDxe in OVMF, so the dependency will always be satisfied. I tested this change as follows: - I dumped the ACPI tables in a Fedora 20 guest, before and after the change, and compared them. The only thing that actually changed was the FACS address. (Which I promptly tested with S3 suspend/resume.) Plus, of course, the FACP checksum changed, because the FACP links the FACS. - Tested S3 in my Windows Server 2008 R2 and Windows Server 2012 R2 guests. 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@16411 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe: Fix VS2012 IA32 build warningJordan Justen2014-09-251-2/+2
| | | | | | | | 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@16170 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interfaceLaszlo Ersek2014-09-222-4/+636
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recent changes in the QEMU ACPI table generator have shown that our limited client for that interface is insufficient and/or brittle. Implement the full interface utilizing OrderedCollectionLib for addressing fw_cfg blobs by name. In order to stay compatible with EFI_ACPI_TABLE_PROTOCOL, we don't try to identify QEMU's RSD PTR and link it into the UEFI system configuration table. Instead, once all linker/loader commands have been processed, we process the AddPointer commands for a second time. In the second pass, we look at the targets of these pointer commands. The key idea (by Michael Tsirkin) is that any ACPI interpreter will only be able to locate ACPI tables by following absolute pointers, hence QEMU's set of AddPointer commands will cover all of the ACPI tables (and more, see below). Some of QEMU's AddPointer commands (ie. some fields in ACPI tables) may point to areas in fw_cfg blobs that are not ACPI tables themselves. Examples are the BGRT.ImageAddress field, and the TCPA.LASA field. We tell these apart from ACPI tables by performing the following checks on pointer target "candidates": - length check against minimum ACPI table size, and remaining blob size - checksum verification. If a target area looks like an ACPI table, and is different from RSDT and DSDT (which EFI_ACPI_TABLE_PROTOCOL handles internally), we install the table (at which point EFI_ACPI_TABLE_PROTOCOL creates a deep copy of the relevant segment of the pointed-to fw_cfg blob). Simultaneously, we keep account if each fw_cfg blob has ever been referenced as the target of an AddPointer command without that AddPointer command actually identifying an ACPI table. In this case the containing fw_cfg file (of AcpiNVS memory type) must remain around forever, because we never install that area with EFI_ACPI_TABLE_PROTOCOL, but some field in some ACPI table that we *do* install still references it, by the absolute address that we've established during the first pass. 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@16158 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: AcpiPlatformDxe: remove current ACPI table loaderLaszlo Ersek2014-09-221-337/+1
| | | | | | | | | | | | | | | | | | | | | | In the next patch we rewrite the client code for QEMU's fw_cfg ACPI table loader interface. In order to avoid randomly intermixed hunks in that patch, first remove the old code cleanly. We remove the InstallQemuLinkedTables() function and empty the InstallAllQemuLinkedTables() function. We also remove CheckRsdp(). InstallAllQemuLinkedTables() will return constant EFI_NOT_FOUND to AcpiPlatformEntryPoint(), causing the latter to proceed to OVMF's builtin tables. This way the history remains bisectable and the new client gets a clean start in the next patch. 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@16157 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: AcpiPlatformDxe: actualize QemuLoader.h commentsLaszlo Ersek2014-09-221-5/+1
| | | | | | | | | | | We used to state in this header file that we only cared about the Allocate command. This is no longer the case; update the comments accordingly. 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@16156 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: AcpiPlatformDxe: don't rely on unstable QEMU interfaceLaszlo Ersek2014-06-192-5/+139
| | | | | | | | | | | | | | | | | | The fw_cfg file "etc/acpi/tables" is not a stable guest interface -- QEMU could rename it in the future, and/or introduce additional fw_cfg files with ACPI payload. Only the higher-level "etc/table-loader" file is considered stable, which contains a sequence of commands to assist firmware with reading QEMU ACPI tables from the FwCfg interface. Because edk2 provides publishing support for ACPI tables, OVMF only uses the Allocate command to find the names of FwCfg files to read and publish as ACPI tables. 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@15574 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: AcpiPlatformDxe: exclude RSD PTR from QEMU's fw_cfg payloadLaszlo Ersek2014-06-191-0/+104
| | | | | | | | | | | | | | | In one of the next patches we'll start scanning all fw_cfg files that QEMU advertises as carrying ACPI tables, not just "etc/acpi/tables". The RSD PTR table is known to occur in the "etc/acpi/rsdp" fw_cfg file. Since edk2 handles RSD PTR automatically, similarly to RSDT and XSDT, let's exclude RSD PTR too from the manually installed tables. 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@15573 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: AcpiPlatformDxe: pass FwCfgFile to InstallQemuLinkedTables()Laszlo Ersek2014-06-193-47/+112
| | | | | | | | | | | | | | | | Split InstallQemuLinkedTables() in two: - the function now takes the name of the fw_cfg file (from which ACPI tables are to be extracted) as a parameter, - the new function InstallAllQemuLinkedTables() calls the former with fw_cfg file names, and cumulatively tracks the ACPI tables installed by all invocations of the former. 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@15572 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-28 18:33:53 +0000