On Fri, 1 Aug 2025 at 12:03, Igor Mammedov <imamm...@redhat.com> wrote: > > On Thu, 31 Jul 2025 15:20:29 +0300 > Manos Pitsidianakis <manos.pitsidiana...@linaro.org> wrote: > > Yes. Our motivation for this patch is just feature parity with x86. > > It's a nice-to-have, if it's possible. > > if it's parity with x86, then why not use acpi like x86 does? > > If I'm not mistaken, DT in arm/virt was mostly intended to bootstrap > 1st steps of firmware, and the preferred way do get other info from QEMU > was via fw_cfg or standard enumeration methods (PCI/ACPI/...).
For the virt board, both DT and ACPI are intended to be generally on parity with each other for feature support. Typically you use ACPI if you're booting into UEFI to boot a kernel, and you use DT if you're doing a direct kernel boot. The former is a bit closer to a "real hardware" setup, and the latter is faster and usually simpler. > (point is: do not duplicate acpi features in DT for arm/virt machine type, > perhaps arm/sbsa-ref is a better target for DT). No, sbsa-ref is intended as an exclusively ACPI setup: it's the board type that is a reference platform for full-firmware-stack development. Although it has a "DT" of sorts, this is not a real DT, it's just a convenient way of communicating a few critical bits of information to the firmware. The guest kernel will never see this DT, only the ACPI tables from the firmware. thanks -- PMM