Re: [Qemu-arm] [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise machine type

[Ard Biesheuvel]

On 30 August 2018 at 18:36, Peter Maydell <address@hidden> wrote:
> On 30 August 2018 at 14:29, Ard Biesheuvel <address@hidden> 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.