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>
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>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
"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
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
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
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
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
Volker Rümelin
Laszlo Ersek
Jordan Justen
jljusten
ydong10