From: Laszlo Ersek <lersek@redhat.com>
To: SeaBIOS@seabios.org, qemu-devel@nongnu.org, edk2-devel@lists.01.org
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Ben Warren <ben@skyportsystems.com>,
Dongjiu Geng <gengdongjiu@huawei.com>,
Igor Mammedov <imammedo@redhat.com>,
Jordan Justen <jordan.l.justen@intel.com>,
Leif Lindholm <leif.lindholm@linaro.org>,
Shannon Zhao <zhaoshenglong@huawei.com>
Subject: [edk2 PATCH 1/3] OvmfPkg/AcpiPlatformDxe: rename BLOB.HostsOnlyTableData to BLOB.Releasable
Date: Fri, 2 Jun 2017 18:03:30 +0200 [thread overview]
Message-ID: <20170602160332.1939-2-lersek@redhat.com> (raw)
In-Reply-To: <20170602160332.1939-1-lersek@redhat.com>
The "BLOB.HostsOnlyTableData" field tracks whether the allocated &
downloaded fw_cfg blob should be released in the end. The current name
"HostsOnlyTableData" reflects only the original determinant for this,
namely whether the blob hosts ACPI table data only -- because in that case
EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() would create deep copies of all
referenced parts of the blob.
However, in commit 9965cbd424f2 ("OvmfPkg/AcpiPlatformDxe: implement the
QEMU_LOADER_WRITE_POINTER command", 2017-02-08) we flipped the field to
FALSE in ProcessCmdWritePointer() too, because the blob must also not be
released if we send its allocation address back to QEMU. Therefore we
should more generally call the field "Releasable".
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Warren <ben@skyportsystems.com>
Cc: Dongjiu Geng <gengdongjiu@huawei.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c | 22 ++++++++++----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
index 1bc5fe297a96..4a7b051288bc 100644
--- a/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
+++ b/OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
@@ -34,13 +34,12 @@ typedef struct {
UINT8 File[QEMU_LOADER_FNAME_SIZE]; // NUL-terminated name of the fw_cfg
// blob. This is the ordering / search
// key.
UINTN Size; // The number of bytes in this blob.
UINT8 *Base; // Pointer to the blob data.
- BOOLEAN HostsOnlyTableData; // TRUE iff the blob has been found to
- // only contain data that is directly
- // part of ACPI tables.
+ BOOLEAN Releasable; // TRUE iff the blob should be released
+ // at the end of processing.
} BLOB;
/**
Compare a standalone key against a user structure containing an embedded key.
@@ -206,11 +205,11 @@ ProcessCmdAllocate (
goto FreePages;
}
CopyMem (Blob->File, Allocate->File, QEMU_LOADER_FNAME_SIZE);
Blob->Size = FwCfgSize;
Blob->Base = (VOID *)(UINTN)Address;
- Blob->HostsOnlyTableData = TRUE;
+ Blob->Releasable = TRUE;
Status = OrderedCollectionInsert (Tracker, NULL, Blob);
if (Status == RETURN_ALREADY_STARTED) {
DEBUG ((EFI_D_ERROR, "%a: duplicated file \"%a\"\n", __FUNCTION__,
Allocate->File));
@@ -505,11 +504,11 @@ ProcessCmdWritePointer (
//
// Because QEMU has now learned PointeeBlob->Base, we must mark PointeeBlob
// as unreleasable, for the case when the whole linker/loader script is
// handled successfully.
//
- PointeeBlob->HostsOnlyTableData = FALSE;
+ PointeeBlob->Releasable = FALSE;
DEBUG ((DEBUG_VERBOSE, "%a: PointerFile=\"%a\" PointeeFile=\"%a\" "
"PointerOffset=0x%x PointeeOffset=0x%x PointerSize=%d\n", __FUNCTION__,
WritePointer->PointerFile, WritePointer->PointeeFile,
WritePointer->PointerOffset, WritePointer->PointeeOffset,
@@ -612,12 +611,13 @@ UndoCmdWritePointer (
before, or an ACPI table different from RSDT
and XSDT has been installed (reflected by
InstalledKey and NumInstalled), or RSDT or
XSDT has been identified but not installed, or
the fw_cfg blob pointed-into by AddPointer has
- been marked as hosting something else than
- just direct ACPI table contents.
+ been marked as non-releasable due to hosting
+ something else than just direct ACPI table
+ contents.
@return Error codes returned by
AcpiProtocol->InstallAcpiTable().
**/
STATIC
@@ -740,11 +740,11 @@ Process2ndPassCmdAddPointer (
}
}
if (TableSize == 0) {
DEBUG ((EFI_D_VERBOSE, "not found; marking fw_cfg blob as opaque\n"));
- Blob2->HostsOnlyTableData = FALSE;
+ Blob2->Releasable = FALSE;
return EFI_SUCCESS;
}
if (*NumInstalled == INSTALLED_TABLES_MAX) {
DEBUG ((EFI_D_ERROR, "%a: can't install more than %d tables\n",
@@ -982,23 +982,23 @@ RollbackWritePointersAndFreeTracker:
}
}
//
// Tear down the tracker infrastructure. Each fw_cfg blob will be left in
- // place only if we're exiting with success and the blob hosts data that is
- // not directly part of some ACPI table.
+ // place only if we're exiting with success and the blob has been marked
+ // non-releasable.
//
for (TrackerEntry = OrderedCollectionMin (Tracker); TrackerEntry != NULL;
TrackerEntry = TrackerEntry2) {
VOID *UserStruct;
BLOB *Blob;
TrackerEntry2 = OrderedCollectionNext (TrackerEntry);
OrderedCollectionDelete (Tracker, TrackerEntry, &UserStruct);
Blob = UserStruct;
- if (EFI_ERROR (Status) || Blob->HostsOnlyTableData) {
+ if (EFI_ERROR (Status) || Blob->Releasable) {
DEBUG ((EFI_D_VERBOSE, "%a: freeing \"%a\"\n", __FUNCTION__,
Blob->File));
gBS->FreePages ((UINTN)Blob->Base, EFI_SIZE_TO_PAGES (Blob->Size));
}
FreePool (Blob);
--
2.9.3
next prev parent reply other threads:[~2017-06-02 16:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-02 15:45 allocation zone extensions for the firmware linker/loader Laszlo Ersek
2017-06-02 15:59 ` [qemu PATCH 0/7] bios-linker-loader: introduce the NOACPI hint and the 64-bit zone for ALLOCATE Laszlo Ersek
2017-06-02 16:00 ` [qemu PATCH 1/7] hw/acpi/bios-linker-loader: expose allocation zone as an enum Laszlo Ersek
2017-06-02 16:00 ` [qemu PATCH 2/7] hw/acpi/bios-linker-loader: introduce "no ACPI tables" content hint for ALLOC Laszlo Ersek
2017-06-02 16:00 ` [qemu PATCH 3/7] hw/acpi/bios-linker-loader: introduce BIOS_LINKER_LOADER_ALLOC_ZONE_64BIT Laszlo Ersek
2017-06-02 16:00 ` [qemu PATCH 4/7] hw/acpi/nvdimm: ask the firmware to allocate NVDIMM_DSM_MEM_FILE as NOACPI Laszlo Ersek
2017-06-02 16:00 ` [qemu PATCH 5/7] hw/acpi/vmgenid: ask the fw to alloc VMGENID_GUID_FW_CFG_FILE " Laszlo Ersek
2017-06-02 16:00 ` [qemu PATCH 6/7] hw/i386/acpi-build: ask the fw to alloc ACPI_BUILD_TPMLOG_FILE with 64bit/NOACPI Laszlo Ersek
2017-06-02 16:00 ` [qemu PATCH 7/7] hw/arm/virt-acpi-build: make the fw alloc blobs with ACPI tables as 64bit Laszlo Ersek
2017-06-02 16:02 ` [seabios PATCH 0/2] romfile_loader: cope with the UEFI-oriented allocation extensions Laszlo Ersek
2017-06-02 16:02 ` [seabios PATCH 1/2] romfile_loader: alloc: cope with the UEFI-oriented NOACPI content hint Laszlo Ersek
2017-06-02 16:02 ` [seabios PATCH 2/2] romfile_loader: alloc: cope with the UEFI-oriented 64BIT zone hint Laszlo Ersek
2017-06-02 16:03 ` [edk2 PATCH 0/3] OvmfPkg/AcpiPlatformDxe: NOACPI hint and 64-bit zone in fw_cfg blob alloc Laszlo Ersek
2017-06-02 16:03 ` Laszlo Ersek [this message]
2017-06-02 16:03 ` [edk2 PATCH 2/3] OvmfPkg/AcpiPlatformDxe: support NOACPI content hint in ALLOCATE command Laszlo Ersek
2017-06-02 16:03 ` [edk2 PATCH 3/3] OvmfPkg/AcpiPlatformDxe: support 64-bit zone " Laszlo Ersek
[not found] ` <20170602191230-mutt-send-email-mst@kernel.org>
2017-06-02 23:20 ` allocation zone extensions for the firmware linker/loader Laszlo Ersek
2017-06-03 7:36 ` Laszlo Ersek
2017-06-05 9:54 ` [Qemu-devel] " Igor Mammedov
2017-06-06 17:52 ` Laszlo Ersek
[not found] ` <20170605185815-mutt-send-email-mst@kernel.org>
2017-06-06 18:10 ` Laszlo Ersek
[not found] ` <20170608204207-mutt-send-email-mst@kernel.org>
2017-06-12 16:05 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170602160332.1939-2-lersek@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox