On 13/10/2020 16:54, Jan Beulich wrote: > On 13.10.2020 17:47, Igor Druzhinin wrote: >> 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. > > I guess this is simply a misunderstanding. I'm not talking about > your change or hvmloader or the boot loader at all. I was merely > noticing a consequence of your findings on the behavior of Xen > itself: Use of ACPI and use of E801 are exclusive of one another.
Sorry, yes. I forgot e801 is also used by Xen as an alternative to e820. Igor
