summaryrefslogtreecommitdiff
path: root/OvmfPkg/AcpiPlatformDxe
AgeCommit message (Collapse)Author
2015-02-19OvmfPkg: AcpiPlatformDxe: make dependency on PCI enumeration dynamicLaszlo Ersek
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
2015-02-19OvmfPkg: AcpiPlatformDxe: extract common entry pointLaszlo Ersek
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
2015-02-19OvmfPkg/AcpiPlatformDxe: InstallAllQemuLinkedTables => InstallQemuFwCfgTablesJordan Justen
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
2015-02-19OvmfPkg/AcpiPlatformDxe: FindAcpiTablesInFv => InstallOvmfFvTablesJordan Justen
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
2015-02-17OvmfPkg/AcpiPlatformDxe: Assert if AcpiTable protocol is not foundJordan Justen
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
2015-02-17OvmfPkg/QemuFwCfgAcpiPlatformDxe: Move entry point to QemuFwCfgAcpi.cJordan Justen
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
2015-02-02OvmfPkg/AcpiPlatformDxe: Add QEMU fw-cfg only driverJordan Justen
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
2015-02-02OvmfPkg/AcpiPlatformDxe: Split QEMU fw-cfg into a new fileJordan Justen
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
2014-11-20OvmfPkg: AcpiPlatformDxe: make dependency on PCI enumeration explicitLaszlo Ersek
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
2014-09-25OvmfPkg/AcpiPlatformDxe: Fix VS2012 IA32 build warningJordan Justen
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
2014-09-22OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interfaceLaszlo Ersek
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
2014-09-22OvmfPkg: AcpiPlatformDxe: remove current ACPI table loaderLaszlo Ersek
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
2014-09-22OvmfPkg: AcpiPlatformDxe: actualize QemuLoader.h commentsLaszlo Ersek
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
2014-06-19OvmfPkg: AcpiPlatformDxe: don't rely on unstable QEMU interfaceLaszlo Ersek
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
2014-06-19OvmfPkg: AcpiPlatformDxe: exclude RSD PTR from QEMU's fw_cfg payloadLaszlo Ersek
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
2014-06-19OvmfPkg: AcpiPlatformDxe: pass FwCfgFile to InstallQemuLinkedTables()Laszlo Ersek
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
2014-03-31OvmfPkg: AcpiPlatformDxe: download ACPI tables from QEMULaszlo Ersek
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
2013-11-12OvmfPkg/AcpiPlatformDxe/Qemu: Decrease upper limit for PCI window 32Jordan Justen
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
2013-02-14OvmfPkg/AcpiPlatformDxe: split S3/S4 package into bytesjljusten
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
2012-12-17OvmfPkg: create \_S3 and \_S4 packages dynamicallyjljusten
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
2012-08-15OvmfPkg/AcpiPlatformDxe: Fix Visual Studio build issuesjljusten
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
2012-08-13OvmfPkg: generate full MADT dynamically, synchronize contents with qemujljusten
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
2012-08-09OvmfPkg/AcpiPlatformDxe: Fix Visual Studio build issuesjljusten
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
2012-07-31OvmfPkg: scan memory space map and populate FWDT (32-bit fields only)jljusten
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
2012-07-31OvmfPkg: install an SSDT with a dynamic OperationRegion called FWDTjljusten
"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
2012-07-18OvmfPkg/AcpiPlatformDxe: rely on built-in checksummingjljusten
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
2012-07-18OvmfPkg/AcpiPlatformDxe/Xen.c: reuse CalculateSum8jljusten
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
2012-07-18OvmfPkg/AcpiPlatformDxe: Add Xen ACPI tables supportjljusten
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
2012-06-07Fix file guid conflict.ydong10
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
2012-06-01OvmfPkg/AcpiPlatformDxe: Fix VS2010 build issuejljusten
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
2012-05-30OvmfPkg/AcpiPlatformDxe: Dynamically add Local APIC entries in MADTjljusten
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
2012-05-30OvmfPkg/AcpiPlatformDxe: Detect QEMU & Xenjljusten
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
2012-05-30OvmfPkg: Add AcpiPlatformDxejljusten
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