Commit Graph

51 Commits

Author SHA1 Message Date
Laszlo Ersek 9e2a8e9289 OvmfPkg/AcpiPlatformDxe: short-circuit the transfer of an empty S3_CONTEXT
In commit 8057622527 ("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
    df73df138d ("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 8057622527.

Cc: Dhiru Kholia <dhiru.kholia@gmail.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Fixes: df73df138d
Fixes: 8057622527
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>
2017-08-08 15:10:45 +02:00
Ard Biesheuvel 8f98c76f99 OvmfPkg/AcpiPlatformDxe: fix spurious uninitialized var warning
Commit 4275f38507 ("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>
2017-06-09 08:57:39 +00:00
Laszlo Ersek 4275f38507 OvmfPkg/AcpiPlatformDxe: alloc blobs from 64-bit space unless restricted
... 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>
2017-06-08 00:49:02 +02:00
Phil Dennis-Jordan 072060a6f8 OvmfPkg: Allow multiple add-pointer linker commands to same ACPI table
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>
2017-03-30 21:53:13 +02:00
Laszlo Ersek 8057622527 OvmfPkg/AcpiPlatformDxe: save fw_cfg boot script with QemuFwCfgS3Lib
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>
2017-03-14 21:49:38 +01:00
Laszlo Ersek 687f7521ea ArmVirtPkg, OvmfPkg: retire QemuFwCfgS3Enabled() from QemuFwCfgLib
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>
2017-03-14 21:49:16 +01:00
Laszlo Ersek ed1a2d42d5 OvmfPkg/QemuFwCfg: introduce FW_CFG_IO_DMA_ADDRESS, adapt the package
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>
2017-02-22 03:35:49 +01:00
Laszlo Ersek 6025488da3 OvmfPkg/AcpiPlatformDxe: update PointerValue comments in "BootScript.c"
Commit df73df138d ("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>
2017-02-22 03:35:37 +01:00
Laszlo Ersek a3be3b6597 OvmfPkg/AcpiPlatformDxe: drop double right shift in ADD/WRITE POINTER cmds
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>
2017-02-22 03:35:18 +01:00
Laszlo Ersek df73df138d OvmfPkg/AcpiPlatformDxe: replay QEMU_LOADER_WRITE_POINTER commands at S3
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>
2017-02-21 13:10:42 +01:00
Laszlo Ersek 9965cbd424 OvmfPkg/AcpiPlatformDxe: implement the QEMU_LOADER_WRITE_POINTER command
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>
2017-02-21 13:10:39 +01:00
Laszlo Ersek ab63766baf OvmfPkg/AcpiPlatformDxe: rewrap license block in "QemuFwCfgAcpi.c"
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>
2017-02-21 13:10:36 +01:00
Laszlo Ersek 774f52f6de OvmfPkg/AcpiPlatformDxe: add QEMU_LOADER_WRITE_POINTER definitions
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>
2017-02-21 13:10:33 +01:00
Laszlo Ersek 75ccd1d89e OvmfPkg/AcpiPlatformDxe: prepare for QEMU_LOADER_WRITE_POINTER definitions
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>
2017-02-21 13:10:05 +01:00
Thomas Huth 8c0b0b34f7 OvmfPkg: Fix typing errors
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>
2016-09-12 13:12:32 +02:00
Volker Rümelin 90bb4c577d OvmfPkg: AcpiPlatformDxe: Don't enable unsupported PCI attributes
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>
2016-04-19 13:18:34 +02:00
Laszlo Ersek 8f35eb92c4 OvmfPkg: AcpiPlatformDxe: enable PCI IO and MMIO while fetching QEMU tables
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>
2016-03-23 17:39:35 +01:00
Laszlo Ersek b6bc800d5a OvmfPkg: AcpiPlatformDxe: when PCI is enabled, wait for Platform BDS's cue
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>
2016-03-23 17:39:35 +01:00
Laszlo Ersek 818bc86aa7 OvmfPkg: AcpiPlatformDxe: make dependency on PCI enumeration dynamic
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-19 23:46:27 +00:00
Laszlo Ersek 04951644cd OvmfPkg: AcpiPlatformDxe: extract common entry point
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-19 23:45:57 +00:00
Jordan Justen f186536bdd OvmfPkg/AcpiPlatformDxe: InstallAllQemuLinkedTables => InstallQemuFwCfgTables
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-19 23:45:50 +00:00
Jordan Justen b70c4d07f3 OvmfPkg/AcpiPlatformDxe: FindAcpiTablesInFv => InstallOvmfFvTables
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-19 23:45:42 +00:00
Jordan Justen 53596a72cd OvmfPkg/AcpiPlatformDxe: Assert if AcpiTable protocol is not found
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-17 18:58:05 +00:00
Jordan Justen 903f52297f OvmfPkg/QemuFwCfgAcpiPlatformDxe: Move entry point to QemuFwCfgAcpi.c
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-17 00:14:58 +00:00
Jordan Justen 48b850898b OvmfPkg/AcpiPlatformDxe: Add QEMU fw-cfg only driver
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-02 19:09:02 +00:00
Jordan Justen 14b0faadfc OvmfPkg/AcpiPlatformDxe: Split QEMU fw-cfg into a new file
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
2015-02-02 19:08:57 +00:00
Laszlo Ersek 66b280df28 OvmfPkg: AcpiPlatformDxe: make dependency on PCI enumeration explicit
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-11-20 09:58:28 +00:00
Jordan Justen ce88384500 OvmfPkg/AcpiPlatformDxe: Fix VS2012 IA32 build warning
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-25 02:29:00 +00:00
Laszlo Ersek 387536e472 OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader interface
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-22 21:11:22 +00:00
Laszlo Ersek 56947bc081 OvmfPkg: AcpiPlatformDxe: remove current ACPI table loader
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-22 21:11:15 +00:00
Laszlo Ersek 10de33ec2d OvmfPkg: AcpiPlatformDxe: actualize QemuLoader.h comments
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-09-22 21:11:09 +00:00
Laszlo Ersek a618eaa1f4 OvmfPkg: AcpiPlatformDxe: don't rely on unstable QEMU interface
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-19 06:13:29 +00:00
Laszlo Ersek 374df8fc59 OvmfPkg: AcpiPlatformDxe: exclude RSD PTR from QEMU's fw_cfg payload
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-19 06:13:22 +00:00
Laszlo Ersek 2d1fe95066 OvmfPkg: AcpiPlatformDxe: pass FwCfgFile to InstallQemuLinkedTables()
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-06-19 06:13:12 +00:00
Laszlo Ersek 96bbdbc856 OvmfPkg: AcpiPlatformDxe: download ACPI tables from QEMU
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
2014-03-31 20:36:06 +00:00
Jordan Justen 2662fa8dcd OvmfPkg/AcpiPlatformDxe/Qemu: Decrease upper limit for PCI window 32
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-11-12 18:34:36 +00:00
jljusten 3d80db51f4 OvmfPkg/AcpiPlatformDxe: split S3/S4 package into bytes
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
2013-02-14 19:20:57 +00:00
jljusten 14430c55c8 OvmfPkg: create \_S3 and \_S4 packages dynamically
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-12-17 02:13:14 +00:00
jljusten ff8dd312dd OvmfPkg/AcpiPlatformDxe: Fix Visual Studio build issues
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-15 00:03:35 +00:00
jljusten 498f7d8ddd OvmfPkg: generate full MADT dynamically, synchronize contents with qemu
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-13 15:42:07 +00:00
jljusten 26af9aca92 OvmfPkg/AcpiPlatformDxe: Fix Visual Studio build issues
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-08-09 23:27:05 +00:00
jljusten 57c0beb609 OvmfPkg: scan memory space map and populate FWDT (32-bit fields only)
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-31 18:18:01 +00:00
jljusten 253a2ea73f OvmfPkg: install an SSDT with a dynamic OperationRegion called FWDT
"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-31 18:17:51 +00:00
jljusten b5c91f01d2 OvmfPkg/AcpiPlatformDxe: rely on built-in checksumming
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-18 22:34:01 +00:00
jljusten 4804ef4943 OvmfPkg/AcpiPlatformDxe/Xen.c: reuse CalculateSum8
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-18 22:33:48 +00:00
jljusten 377e758c3f OvmfPkg/AcpiPlatformDxe: Add Xen ACPI tables support
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-07-18 22:33:33 +00:00
ydong10 917ab9077d Fix file guid conflict.
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-07 03:21:17 +00:00
jljusten 75ccc2b211 OvmfPkg/AcpiPlatformDxe: Fix VS2010 build issue
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-06-01 17:55:00 +00:00
jljusten 255b418415 OvmfPkg/AcpiPlatformDxe: Dynamically add Local APIC entries in MADT
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-30 23:15:59 +00:00
jljusten 522203de37 OvmfPkg/AcpiPlatformDxe: Detect QEMU & Xen
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-30 23:15:27 +00:00