On Tue, Jul 07, 2020 at 11:15:30AM +0100, Peter Maydell wrote: > On Tue, 7 Jul 2020 at 11:04, Andrew Jones <drjo...@redhat.com> wrote: > > This seems a bit messy to me. With an EL3 firmware, the DTB is provided > > by the EL3 firmware. I guess that's why when I look at the DTB generation > > in virt.c we don't properly set "enable-method" of the CPUs to > > "spin-table", even though we don't set it to "psci"[*]. > > Well, there's no way in the DTB to say "all the CPUs start at once" :-) > "spin-table" would be just as wrong as "psci" for us in that case. > > > So, I think the EL3 firmware should also provide the ACPI tables. > > Mmm, but I thought the general design for QEMU was that we have > to help the EL3 firmware along by providing ACPI fragments for it > to assemble. As I understand it, this is a pragmatic decision > because the binary format of a complete ACPI table is painful > to edit. So I suppose one question here is "if QEMU doesn't set > the PSCI flag in the ACPI tables, how hard is it for the EL3 > firmware to edit the table to add the flag?". > > > However, this patch it probably fine too. For a configuration where > > the EL3 firmware provides the ACPI tables, it will do no harm. For > > configurations where EL3 firmware isn't involved, it will do no harm. > > And, for configurations like this, which I consider a bit hacky, it's > > probably better to assume PSCI than not. > > Is this really a 'hacky' configuration? I sort of expected it to > be a fairly common one for the 'virt' board. (For sbsa-ref the > EL3 firmware would provide a complete canned ACPI table, I think, > but for virt it can't and shouldn't do that.)
IMO, if the EL3 firmware is providing the complete DTB, then it should provide the complete ACPI tables. Otherwise we should expose machine properties allowing the virt board to generate both DTB and ACPI for an EL3 firmware configuration. The other option of using fw-cfg to tweak ACPI tables may work too, but only for tweaks. If the EL3 firmware controlled DTB changed in a way that diverges too much from QEMU's ACPI generation, then there'd still be a problem. Thanks, drew
