On Mon, Dec 23, 2024 at 06:18:03PM +0000, Dmytro Maluka wrote:
> There are cases when the bootloader provides information to the kernel
> in both ACPI and DTB, not interchangeably. One such use case is virtual
> machines in Android. When running on x86, the Android Virtualization
> Framework (AVF) boots VMs with ACPI like it is usually done on x86 (i.e.
> the virtual LAPIC, IOAPIC, HPET, PCI MMCONFIG etc are described in ACPI)
> but also passes various AVF-specific boot parameters in DTB. This allows
> reusing the same implementations of various AVF components on both
> arm64 and x86.
Anyone booting Arm ACPI based systems with AVF?
Where's this AVF binding documented?
> Commit 7b937cc243e5 ("of: Create of_root if no dtb provided by firmware")
> removed the possibility to do that, since among other things
> it introduced forcing emptying the bootloader-provided DTB if ACPI is
> enabled (probably assuming that if ACPI is available, a DTB can only be
> useful for applying overlays to it afterwards, for testing purposes).
>
> So restore this possibility. At the same time, since the aforementioned
> recently introduced restriction is actually useful for preventing
> conflicts between ACPI and DT for LAPIC/IOAPIC/HPET setup, don't remove
> this restriction completely but relax it: unflatten the bootloader
> supplied DTB but don't try to use it for SMP setup (i.e. don't override
> the .parse_smp_cfg callback) if ACPI is enabled. Precisely, right now
> this prevents at least:
>
> - incorrectly calling register_lapic_address(APIC_DEFAULT_PHYS_BASE)
> after the LAPIC was already successfully enumerated via ACPI, causing
> noisy kernel warnings and probably potential real issues as well
>
> - failed IOAPIC setup in the case when IOAPIC is enumerated via mptable
> instead of ACPI (e.g. with acpi=noirq), due to
> mpparse_parse_smp_config() overridden by x86_dtb_parse_smp_config()
It would be better if we explicitly opt'ed into "things we want to get
from DT" rather than allowing anything except what we check for. There's
a strong desire at least for arm64 to prevent systems from using both
at the same time. There are growing usecases for doing just that, but I
think we need to have some control or restrictions in place to define
what we support in the kernel.
> Fixes: 7b937cc243e5 ("of: Create of_root if no dtb provided by firmware")
> Signed-off-by: Dmytro Maluka <dmaluka@xxxxxxxxxxxx>
> ---
> arch/x86/kernel/devicetree.c | 3 ++-
> drivers/of/fdt.c | 10 +---------
> 2 files changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
> index 59d23cdf4ed0..dd8748c45529 100644
> --- a/arch/x86/kernel/devicetree.c
> +++ b/arch/x86/kernel/devicetree.c
> @@ -2,6 +2,7 @@
> /*
> * Architecture specific OF callbacks.
> */
> +#include <linux/acpi.h>
> #include <linux/export.h>
> #include <linux/io.h>
> #include <linux/interrupt.h>
> @@ -313,6 +314,6 @@ void __init x86_flattree_get_config(void)
> if (initial_dtb)
> early_memunmap(dt, map_len);
> #endif
> - if (of_have_populated_dt())
> + if (acpi_disabled && of_have_populated_dt())
> x86_init.mpparse.parse_smp_cfg = x86_dtb_parse_smp_config;
I would make this a separate patch. Then it can be backported to kernel
versions without 7b937cc243e5. And then Thomas can take it and I can
take the DT part.
> }
