Re: [RFC PATCH] OvmfPkg/AcpiPlatformDxe: lift 4 GB alloc limit for modern ACPI systems

[Laszlo Ersek <lersek@redhat.com>]

On 06/01/17 17:16, Igor Mammedov wrote:
> On Thu, 1 Jun 2017 14:25:48 +0200
> Laszlo Ersek <lersek@redhat.com> wrote:
> 
>> On 06/01/17 13:22, Ard Biesheuvel wrote:
>>> ACPI supports architectures such as arm64, which did not exist when the
>>> original 32-bit ACPI 1.0 was introduced. These days, ACPI tables can all
>>> support 64-bit memory addresses, and so QEMU has been updated to emit
>>> 64-bit table and entry point types on arm64/mach-virt.  
>>
>> Do you have commit cb51ac2ffe36 ("hw/arm/virt: generate 64-bit
>> addressable ACPI objects", 2017-04-10) in mind?

> My understanding was that OVMF discards RSDP/[RX]SDT so that commit
> probably irrelevant.

OVMF does not install these root tables, that's correct, but it does
execute the commands that refer to the blob(s) that contain these
tables. So for example pointers and checksums are updated, it's only the
last heuristics phase that detects if a pointer points to RSDT / XSDT
and then those tables are not installed.

OVMF catches pointer field overflows, and rolls back the entire
processing if one occurs. So the commit in question is certainly
relevant; without it, a >4GB allocation address would be added to an
RSDT entry (which is 4-byte wide), and that would fail the entire process.

> Now about FADT or any other blob, do we really need to extend
> loader protocol? Couldn't firmware decide where to allocate
> table based on size in add_pointer commands?
> 
> That might be a bit complicated but on the bright side is that
> it is firmware only change and it should work both on old and
> new qemu without breaking anything.

For this I'd have to pre-scan the ADD_POINTER commands, and for target
blob ever pointed-at by them, find the minimum referring pointer width.
If that minimum width is smaller than 8 bytes, the pointed-at blob must
be allocated under 4GB.

I think this is too complex (it would add a third pass to OVMF's
processing), especially given that we already have a dedicated Zone
field that specifically tells the firmware where the blobs should be
allocated. The goal is to decrease the dirty tricks in OVMF, not
increase them.

Furthermore, this wouldn't help us turn off the SDT header probing in
OVMF (the feature that currently requires those strange AML-level offset
increments, into blobs that don't host ACPI tables). Suppressing the
probe in a nice way surely needs a specific hint, so we might as well
handle both cases with Zone extensions.

Laszlo