summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/AcpiPlatformDxe
Commit message (Collapse)AuthorAgeFilesLines
* 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
* OvmfPkg: AcpiPlatformDxe: download ACPI tables from QEMULaszlo Ersek2014-03-313-7/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recent qemu versions compose all ACPI tables on the host side, according to the target hardware configuration, and make the tables available to any guest firmware over fw_cfg. See version compatibility information below. The feature moves the burden of keeping ACPI tables up-to-date from boot firmware to qemu (which is the source of hardware configuration anyway). This patch adds client code for this feature. Benefits of the qemu-provided ACPI tables include PCI hotplug for example. Qemu provides the following three fw_cfg files: - etc/acpi/rsdp - etc/acpi/tables - etc/table-loader "etc/acpi/rsdp" and "etc/acpi/tables" are similar, they are only kept separate because they have different allocation requirements in SeaBIOS. Both of these fw_cfg files contain preformatted ACPI payload. "etc/acpi/rsdp" contains only the RSDP table, while "etc/acpi/tables" contains all other tables, concatenated. The tables in these two fw_cfg files are filled in by qemu, but two kinds of fields are left incomplete in each table: pointers to other tables, and checksums (which depend on the pointers). Qemu initializes each pointer with a relative offset into the fw_cfg file that contains the pointed-to ACPI table. The final pointer values depend on where the fw_cfg files, holding the pointed-to ACPI tables, will be placed in memory by the guest. That is, the pointer fields need to be "relocated" (incremented) by the base addresses of where "/etc/acpi/rsdp" and "/etc/acpi/tables" will be placed in guest memory. This is where the third file, "/etc/table-loader" comes in the picture. It is a linker/loader script that has several command types: One command type instructs the guest to download the other two files. Another command type instructs the guest to increment ("absolutize") a pointer field (having a relative initial value) in the pointing ACPI table, present in some fw_cfg file, with the dynamic base address of the same (or another) fw_cfg file, holding the pointed-to ACPI table. The third command type instructs the guest to compute checksums over ranges and to store them. In edk2, EFI_ACPI_TABLE_PROTOCOL knows about table relationships -- it handles linkage automatically when a table is installed. The protocol takes care of checksumming too. RSDP is installed automatically. Hence we only need to care about the "etc/acpi/tables" fw_cfg file, determining the boundaries of each ACPI table inside it, and installing those tables. Qemu compatibility information: --------------+---------------------+------------------------------------- qemu version | qemu machine type | effects of the patch --------------+---------------------+------------------------------------- up to 1.6.x | any pc-i440fx | None. OVMF's built-in ACPI tables | | are used. --------------+---------------------+------------------------------------- any | up to pc-i440fx-1.6 | None. OVMF's built-in ACPI tables | | are used. --------------+---------------------+------------------------------------- 1.7.0 | pc-i440fx-1.7 | Potential guest OS crash, dependent | (default for 1.7.0) | on guest RAM size. | | | | DO NOT RUN OVMF on the (1.7.0, | | pc-i440fx-1.7) qemu / machine type | | combination. --------------+---------------------+------------------------------------- 1.7.1 | pc-i440fx-1.7 | OVMF downloads valid ACPI tables | (default for 1.7.1) | from qemu and passes them to the | | guest OS. --------------+---------------------+------------------------------------- 2.0.0-rc0 | pc-i440fx-1.7 or | OVMF downloads valid ACPI tables | later | from qemu and passes them to the | | guest OS. -------------+---------------------+------------------------------------- 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@15420 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe/Qemu: Decrease upper limit for PCI window 32Jordan Justen2013-11-122-1/+2
| | | | | | | | | | | | | | | | | | | | | | | In a later patch we will want to mark the flash memory as a runtime services data memory range. This will allow a new runtime services firmware block driver to read & write flash memory when the OS has set up virtual memory protection. Since this memory range will appear as runtime services data, we need to adjust the limit when scanning for PCI window 32 down to just below the flash device. If we don't adjust the limit, then the algorithm in PopulateFwData will fail because it will see a EfiGcdMemoryTypeSystemMemory memory range just below 4GB. v2: * This patch replaces the v1 patch: "OvmfPkg/AcpiPlatformDxe/Qemu: Allow high runtime memory regions" 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@14837 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe: split S3/S4 package into bytesjljusten2013-02-141-24/+34
| | | | | | | | | | | | | | | | | This should be more compatible with AML parsers in practice since older versions of ACPICA's OS support would not accept the previous OVMF format (despite being spec compliant). (For example, on OpenBSD 5.2 it caused a kernel crash) ACPICA has fixed this issue in: https://github.com/otcshare/acpica/commit/5869690a Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: David Woodhouse <David.Woodhouse@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14130 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: create \_S3 and \_S4 packages dynamicallyjljusten2012-12-171-4/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move these states from the DSDT to the SSDT. Override the default configuration if the host has the following qemu commit: commit 459ae5ea5ad682c2b3220beb244d4102c1a4e332 Author: Gleb Natapov <gleb@redhat.com> Date: Mon Jun 4 14:31:55 2012 +0300 Add PIIX4 properties to control PM system states. This patch adds two things. First it allows QEMU to distinguish between regular powerdown and S4 powerdown. Later separate QMP notification will be added for S4 powerdown. Second it allows S3/S4 states to be disabled from QEMU command line. Some guests known to be broken with regards to power management, but allow to use it anyway. Using new properties management will be able to disable S3/S4 for such guests. Supported system state are passed to a firmware using new fw_cfg file. The file contains 6 byte array. Each byte represents one system state. If byte at offset X has its MSB set it means that system state X is supported and to enter it guest should use the value from lowest 3 bits. Signed-off-by: Gleb Natapov <gleb@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.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> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14003 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe: Fix Visual Studio build issuesjljusten2012-08-151-9/+9
| | | | | | | | 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13634 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: generate full MADT dynamically, synchronize contents with qemujljusten2012-08-132-40/+128
| | | | | | | | | | | | Represent the set of possible PCI link target IRQs with Pcd8259LegacyModeEdgeLevel. This ensures that the 8259 Interrupt Controller code in PcAtChipsetPkg will treat them as level-triggered too. 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13628 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe: Fix Visual Studio build issuesjljusten2012-08-092-3/+3
| | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13602 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: scan memory space map and populate FWDT (32-bit fields only)jljusten2012-07-312-1/+88
| | | | | | | | | | 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: minor cleanup] Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13574 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: install an SSDT with a dynamic OperationRegion called FWDTjljusten2012-07-311-1/+105
| | | | | | | | | | | | | | | | | | | | | | | "FWDT" ("firmware data") is allocated as EfiReservedMemoryType, with AllocateReservedPool(). <MdePkg/Include/Library/MemoryAllocationLib.h> doesn't seem to provide direct access to EfiACPIReclaimMemory, but at this point the former seems sufficient. Based on SeaBIOS commit 2062f2ba by Gerd Hoffmann <kraxel@redhat.com>. v3: - coding style fixes: - BDAT -> FWDT - __packed -> #pragma pack(1) - BFLD -> FIRMWARE_DATA, PCI_WINDOW - Bfld -> FwData - Ssdt.asl: changed license to 2-clause BSDL, paraphrasing Dsdt.asl 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13573 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe: rely on built-in checksummingjljusten2012-07-181-33/+0
| | | | | | | | | | | | | | | | Implementation in "MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c": InstallAcpiTable() SetAcpiTable(... Checksum=TRUE ...) AddTableToList(... Checksum=TRUE ...) AcpiPlatformChecksum() 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13543 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe/Xen.c: reuse CalculateSum8jljusten2012-07-182-36/+6
| | | | | | | | 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13542 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe: Add Xen ACPI tables supportjljusten2012-07-183-52/+370
| | | | | | | | | | | | This patch adds Xen ACPI tables support to OVMF. Use EFI_ACPI_TABLE_PROTOCOL to publish all Xen ACPI tables in OVMF, while keeping the Qemu and KVM support. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bei Guan <gbtju85@gmail.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13541 6f19259b-4bc3-4df7-8a09-765794883524
* Fix file guid conflict.ydong102012-06-071-1/+1
| | | | | | | Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13430 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe: Fix VS2010 build issuejljusten2012-06-011-3/+3
| | | | | | | | Reported-by: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13425 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe: Dynamically add Local APIC entries in MADTjljusten2012-05-302-1/+83
| | | | | | | | | | | | | | | | Update MADT processing for QEMU to add additional Local APIC entries to the MADT. The MADT is still built with a single Local APIC entry. If the AcpiPlatformDxe driver determines that more processors are available, then additional Local APIC entries are added to the MADT at runtime. 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13387 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg/AcpiPlatformDxe: Detect QEMU & Xenjljusten2012-05-305-32/+228
| | | | | | | | | | | | | Detect QEMU & Xen, and allow each to choose how to publish the individual ACPI tables. Currently both paths simply publish the tables unmodified. 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13385 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Add AcpiPlatformDxejljusten2012-05-302-0/+313
This driver is currently a direct copy of MdeModulePkg/Universal/Acpi/AcpiPlatformDxe. 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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13384 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-06 03:25:28 +0000