Re: [PATCH] hvmloader: flip "ACPI data" to ACPI NVS type for ACPI table region

[Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>]

On 13/10/2020 16:35, Jan Beulich wrote:
> On 13.10.2020 14:59, Igor Druzhinin wrote:
>> On 13/10/2020 13:51, Jan Beulich wrote:
>>> As a consequence I think we will also want to adjust Xen itself to
>>> automatically disable ACPI when it ends up consuming E801 data. Or
>>> alternatively we should consider dropping all E801-related code (as
>>> being inapplicable to 64-bit systems).
>>
>> I'm not following here. What Xen has to do with E801? It's a SeaBIOS 
>> implemented
>> call that happened to be used by QEMU option ROM. We cannot drop it from 
>> there
>> as it's part of BIOS spec.
> 
> Any ACPI aware OS has to use E820 (and nothing else). Hence our
> own use of E801 should either be dropped, or lead to the
> disabling of ACPI. Otherwise real firmware using logic similar
> to SeaBIOS'es (but hopefully properly accounting for holes)
> could make us use ACPI table space as normal RAM.

It's not us using it - it's a boot loader from QEMU in a form of option ROM
that works in 16bit pre-OS environment which is not OS and relies on e801 BIOS 
call.
I'm sure any ACPI aware OS does indeed use E820 but the problem here is not an 
OS.

The option ROM is loaded using fw_cfg from QEMU so it's not our code. 
Technically
it's one foreign code (QEMU boot loader) talking to another foreign code 
(SeaBIOS)
which provides information based on E820 that we gave them.

So I'm afraid decision to dynamically disable ACPI (whatever you mean by this)
cannot be made by sole usage of this call by a pre-OS boot loader.

Igor