On 12 November 2014 09:08, Claudio Fontana <claudio.font...@huawei.com> wrote: > As mentioned by others, I'd rather see an implementation of ACPI in QEMU which > learns from the experience of X86 (and possibly shares some code if possible), > rather than going in a different direction by creating device trees first, > and then converting them to ACPI tables somewhere in the firmware, just > because > device trees are "already there", for the reasons which have already been > mentioned before by Igor and others.
I think the motivation for "leave ACPI entirely to the firmware" is not just that the device trees are already there, but because it allows for a cleaner separation of concerns between QEMU and the firmware and thus makes QEMU simpler and easier to maintain in future. However as a result of the discussion in this thread and on IRC about what x86 QEMU/OVMF do and what the complexities of handling this in UEFI are, I'm not as sure as I was that it's actually feasible in practice. I agree with you that if we have QEMU generating ACPI information itself then we should definitely follow the existing tested approach that x86 QEMU+OVMF have, and share code, both in QEMU and in the UEFI firmware. (As I understand it there is a common source code base between OVMF and the Tianocore code we're using for the ARM QEMU UEFI firmware. I've probably got the project names wrong here; I'm not familiar with the distinctions between Tianocore, EDK2, OVMF, etc.) The x86 QEMU-generating-APCI approach is more complicated than what this RFC patchset does, since it generates various separate tables and hands them individually to the firmware, rather than creating a single (non-relocatable) complete ACPI blob. I would hope we didn't need to support both "provide separated tables to firmware" and "provide a single blob to a standalone guest kernel"; if we're agreed that ACPI should imply UEFI we can forget about the latter, though. thanks -- PMM
