On 12 November 2014 09:08, Claudio Fontana claudio.fontana@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