[SeaBIOS] [seabios PATCH 2/2] romfile_loader: alloc: cope with the UEFI-oriented 64BIT zone hint

ROMFILE_LOADER_ALLOC_ZONE_64BIT permits the guest firmware to allocate the blob being downloaded anywhere in the 64-bit address space. In SeaBIOS, we can simply alias this zone request to ROMFILE_LOADER_ALLOC_ZONE_HIGH (i.e., allocate the blob in 32-bit address space.) Cc: "Kevin O'Connor"

[SeaBIOS] [edk2 PATCH 1/3] OvmfPkg/AcpiPlatformDxe: rename BLOB.HostsOnlyTableData to BLOB.Releasable

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

[SeaBIOS] [qemu PATCH 6/7] hw/i386/acpi-build: ask the fw to alloc ACPI_BUILD_TPMLOG_FILE with 64bit/NOACPI

The "etc/tpm/log" fw_cfg blob is guaranteed not to contain ACPI tables, so turning off the ACPI SDT header probe in OVMF is the right thing to do. In addition, the address of the blob is patched into the "TCPA.log_area_start_address" field, which has type "uint64_t". Therefore we can change the

[SeaBIOS] [seabios PATCH 0/2] romfile_loader: cope with the UEFI-oriented allocation extensions

Please see the parent blurb http://mid.mail-archive.com/c76b36de-ebf9-c662-d454-0a95b43901e8@redhat.com> for a high level description. Cc: "Kevin O'Connor" Cc: "Michael S. Tsirkin" Cc: Ard Biesheuvel

[SeaBIOS] [seabios PATCH 1/2] romfile_loader: alloc: cope with the UEFI-oriented NOACPI content hint

OvmfPkg/AcpiPlatformDxe, which implements the client for QEMU's linker/loader in the OVMF and ArmVirtQemu virtual UEFI firmwares, currently relies on a 2nd pass processing of the ADD_POINTER commands, to identify potential ACPI tables in the pointed-to blobs. The reason for this is that ACPI

[SeaBIOS] [qemu PATCH 5/7] hw/acpi/vmgenid: ask the fw to alloc VMGENID_GUID_FW_CFG_FILE as NOACPI

The "etc/vmgenid_guid" fw_cfg blob is guaranteed not to contain ACPI tables, so turning off the ACPI SDT header probe in OVMF is the right thing to do. SeaBIOS needs a patch for recognizing (and masking out) the BIOS_LINKER_LOADER_ALLOC_CONTENT_NOACPI bit, but its behavior will not change. By

Re: [SeaBIOS] allocation zone extensions for the firmware linker/loader

On Fri, Jun 02, 2017 at 05:45:21PM +0200, Laszlo Ersek wrote: > Hi, > > this message is cross-posted to three lists (qemu, seabios, edk2). I'll > follow up with three patch series, one series for each project. I'll > cross-post all of the patches as well, but I'll add the project name in > the

[SeaBIOS] allocation zone extensions for the firmware linker/loader

Hi, this message is cross-posted to three lists (qemu, seabios, edk2). I'll follow up with three patch series, one series for each project. I'll cross-post all of the patches as well, but I'll add the project name in the "bag of tags" in the subject lines. The QEMU series introduces two

[SeaBIOS] [qemu PATCH 0/7] bios-linker-loader: introduce the NOACPI hint and the 64-bit zone for ALLOCATE

Please see the parent blurb http://mid.mail-archive.com/c76b36de-ebf9-c662-d454-0a95b43901e8@redhat.com> for a high level description. Cc: "Michael S. Tsirkin" Cc: Ard Biesheuvel Cc: Ben Warren

[SeaBIOS] [qemu PATCH 4/7] hw/acpi/nvdimm: ask the firmware to allocate NVDIMM_DSM_MEM_FILE as NOACPI

The "etc/acpi/nvdimm-mem" fw_cfg blob is guaranteed not to contain ACPI tables, so turning off the ACPI SDT header probe in OVMF is the right thing to do. SeaBIOS needs a patch for recognizing (and masking out) the BIOS_LINKER_LOADER_ALLOC_CONTENT_NOACPI bit, but its behavior will not change.

[SeaBIOS] [qemu PATCH 1/7] hw/acpi/bios-linker-loader: expose allocation zone as an enum

In a later patch, we'll introduce another allocation zone (which won't fit in the "alloc_fseg" bool). For now, just move the enum constants from "bios-linker-loader.c" to "bios-linker-loader.h", and update the bios_linker_loader_alloc() function prototype so that callers can directly pass in the

[SeaBIOS] [qemu PATCH 2/7] hw/acpi/bios-linker-loader: introduce "no ACPI tables" content hint for ALLOC

OvmfPkg/AcpiPlatformDxe, which implements the client for QEMU's linker/loader in the OVMF and ArmVirtQemu virtual UEFI firmwares, currently relies on a 2nd pass processing of the ADD_POINTER commands, to identify potential ACPI tables in the pointed-to blobs. The reason for this is that ACPI

[SeaBIOS] [qemu PATCH 7/7] hw/arm/virt-acpi-build: make the fw alloc blobs with ACPI tables as 64bit

Thanks to commit cb51ac2ffe36 ("hw/arm/virt: generate 64-bit addressable ACPI objects", 2017-04-10), all pointer fields in the ACPI tables in the "etc/acpi/rsdp" (ACPI_BUILD_RSDP_FILE) and "etc/acpi/tables" (ACPI_BUILD_TABLE_FILE) fw_cfg blobs are 64-bit wide. Therefore we can allow the guest

[SeaBIOS] [edk2 PATCH 0/3] OvmfPkg/AcpiPlatformDxe: NOACPI hint and 64-bit zone in fw_cfg blob alloc

Please see the parent blurb http://mid.mail-archive.com/c76b36de-ebf9-c662-d454-0a95b43901e8@redhat.com> for a high level description. Repo: https://github.com/lersek/edk2.git Branch: zone_hints Cc: "Michael S. Tsirkin" Cc:

[SeaBIOS] [edk2 PATCH 2/3] OvmfPkg/AcpiPlatformDxe: support NOACPI content hint in ALLOCATE command

This driver currently relies on a 2nd pass processing of the ADD_POINTER commands to identify potential ACPI tables in the pointed-to blobs. In order to tell apart ACPI tables from other operation region-like areas within pointed-to blobs, we employ a heuristic called "ACPI SDT header probe" at

[SeaBIOS] [edk2 PATCH 3/3] OvmfPkg/AcpiPlatformDxe: support 64-bit zone in ALLOCATE command

The QemuLoaderAlloc64Bit (3) Zone value permits the guest firmware to allocate the blob being downloaded anywhere in the 64-bit address space. Set the maximum Address value in ProcessCmdAllocate() accordingly. Cc: "Michael S. Tsirkin" Cc: Ard Biesheuvel

Re: [SeaBIOS] allocation zone extensions for the firmware linker/loader

On 06/02/17 18:30, Michael S. Tsirkin wrote: > On Fri, Jun 02, 2017 at 05:45:21PM +0200, Laszlo Ersek wrote: >> Hi, >> >> this message is cross-posted to three lists (qemu, seabios, edk2). I'll >> follow up with three patch series, one series for each project. I'll >> cross-post all of the patches