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

[Laszlo Ersek <lersek@redhat.com>]

On 06/02/17 16:56, Gerd Hoffmann wrote:
>   Hi,
> 
>>  The reason is that old firmware is allowed to fail on new QEMU
>> (regardless of machine type). Example: the WRITE_POINTER command,
>> originally introduced for VMGENID. If you run a SeaBIOS binary
>> without
>> WRITE_POINTER support, in a QEMU VM with "-device vmgenid", the
>> device
>> will not work.
> 
> Old seabios will work just fine on new qemu as long as you don't use
> the vmgenid device.
> 
> Only when using new features (which require firmware support) new
> seabios is needed, and usually we update seabios for that reason.  We
> want the new features be usable of course.  But in general there are no
> lockstep updates for qemu and seabios (any more).
> 
>> And this patch is actually that case, because the new fw would
>> allocate
>> blobs with such 8-byte addresses that might not fit into 32-bit blob
>> fields.
> 
> I think ovmf simply checking whenever the pointer fields are 32bit or
> 64bit, then doing allocations accordingly (as Igor suggested) would be
> the best.  Why ask qemu for a hint when ovmf can figure on its own?
> That adds a new interface and new config knobs for IMO no good reason.

There is a good reason: the reason is that OVMF should not be forced to
reverse-engineer such information with a third, separate pass over the
linker/loader script, adding yet more complexity.

The linker/loader interface was designed for SeaBIOS, without any regard
to OVMF / ArmVirtQemu. For example, SeaBIOS gets hints like HIGH vs.
FSEG (which distinction is irrelevant for OVMF / ArmVirtQemu) despite
the fact that SeaBIOS could also figure that out one way or another if
it really wanted to. OVMF / ArmVirtQemu need different kinds of hints,
and I think they should get them at this point.

Even now, OVMF deduces the starts of individual ACPI tables in the blobs
by using somewhat messy heuristics. (OVMF *must* know where the tables
start.) The heuristics incur no false negatives, but a chance exists for
false positives, unless QEMU takes extra precautions. But Igor happens
to hate those precautions, and the TCPA and NVDIMM authors have
completely missed them. So we should have fewer of these heuristics and
workarounds, not more.

And, as I replied to Igor earlier, the other blob allocation hint (the
"no ACPI content" hint that allows QEMU to drop precisely the above
obscure precautions, i.e. the "ACPI SDT header probe suppressor"),
necessitates extending the ALLOCATE command anyway.

Would it help if I made these extensions dependent on 2.10+ machine
types? (Obviously existing generators like TCPA, NVDIMM and VMGENID
would not be modified then, because the old stuff would have to be
preserved for old machine types anyway.)

Thanks
Laszlo