Re: [PATCH] x86: E801 memory "map" use implies no ACPI

[Jan Beulich <jbeulich@xxxxxxxx>]

On 23.11.2020 13:37, Andrew Cooper wrote:
> On 20/11/2020 12:45, Jan Beulich wrote:
>> ACPI mandates use of E820 (or newer, e.g. EFI), and in fact firmware
>> has been observed to include E820_ACPI ranges in what E801 reports as
>> available (really "configured") memory.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> TBD: Alternatively we could drop all use of E801 (and older), since
>>      there shouldn't be any 64-bit systems not supporting the more
>>      modern E820.
> 
> I'd definitely be in favour of deleting the legacy logic.  The very fact
> that firmware has been observed to include E820_ACPI in E801 maps shows
> that the change here isn't correct in practice.

Mind explaining yourself? I don't see how the change here wouldn't be
correct in practice. Inclusion of ACPI table space in E801 data simply
means either the OS is ACPI-enabled, in which case it won't use E801,
or it's not (or use of ACPI was disabled there by some means) in which
case it's fine to re-use the memory as normal RAM.

> I think we should go further and depend on the bootloader providing the
> memory/video/etc details, which also rips out a lot of 16bit handling
> code in the trampoline.

I wouldn't go this far just yet. We've not been using boot loader
provided memory map data so far, so a first step would imo be to
validate that boot loader provided data is consistent with raw E820
one. We don't want to chance getting screwed up by an old, buggy
boot loader.

> Judging by the context below, I think we should also drop various ACPI
> related options.  Given its ubiquity these days, turning various bits of
> ACPI off is only going to make problems worse.

Probably, but an orthogonal change (and iirc I did recently suggest
the same in a different context). I have to admit that I'd be weary
of regressions if we did so, and if anyone in fact used any of these
options. At the very least I think we would better verbosely deprecate
these (sub)options first, for one or even two release cycles. I still
recall us (SUSE) dropping a custom patch we had been carrying (and
which was rejected upstream) changing the default IO-APIC ack mode for
single IO-APIC systems to old-style, resulting in an instant report
that some director's or even VP's laptop broke. Hence, despite the
upstream rejection, we've now been carrying this change for perhaps
over 10 years. Any change in such areas feels like it could suffer
similar fallout.

Jan