On 30 August 2018 at 18:36, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 30 August 2018 at 14:29, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: >> How exactly the firmware figures out how many CPUs and how much memory >> we are running with is out of scope for this, and so I don't think >> there is a need to build something from scratch here: DT will do just >> fine, given that both EDK2 and ARM-TF have working DT code for these >> things. >> >> fw_cfg, on the other hand, is unsuitable for us. Generating ACPI >> tables in a different way from actual bare metal is not a good idea, >> given that things like RAS interact with ACPI as well, and fw_cfg is >> also exposed to the OS in the default mach-virt configuration. So we >> could tweak fw_cfg to be more suitable, but I think that does not >> improve the usefulness of our prototype at all. > > fw_cfg is an entirely generic transport for passing named > data blobs from QEMU to the other end. You don't have to > pass ACPI table fragments over it the way we do for > virt and the x86 PC platforms if you don't want that.
Sure. But the point is that fw_cfg does not really describe anything that is useful to us. The information that we need in ARM-TF, and -directly or indirectly- in UEFI is currently provided via the DT that is passed in memory, and at the moment, I don't see a reason to change that since it doesn't conflict with the goals we have for this prototype. Relying on an emulated device which should never exist on actual hardware does. > It's true that it's visible to the OS in the sense that it's > a physical device in the system, but so is a hardware connection > to an SCP. > Such a connection would not be exposed to the OS on a arm64 server system.