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

[Hongbo Zhang]

On 30 August 2018 at 21:29, Ard Biesheuvel <address@hidden> wrote:
> On 30 August 2018 at 12:02, Leif Lindholm <address@hidden> wrote:
>> On Thu, Aug 30, 2018 at 09:39:33AM +0100, Peter Maydell wrote:
>>> On 30 August 2018 at 09:31, Leif Lindholm <address@hidden> wrote:
>>> > On Thu, Aug 30, 2018 at 03:07:29PM +0800, Hongbo Zhang wrote:
>>> >> @Ard, @Leif, is there any possibility to remove all the DT nodes?
>>> >> On real hardware, how does UEFI find the memory size and CPU number?
>>> >
>>> > Usually by asking some form of SCP/PMU.
>>> > So until we have rock-solid multi-cpu-instance (making terms up here,
>>> > there may be a proper name already?) support upstream, we need to take
>>> > shortcuts.
>>>
>>> I would expect that you'd want a "faked-on-the-QEMU end" SCP
>>> communications endpoint to start with anyway. We have one of
>>> those for vexpress, for instance.
>>
>> Ah, I wasn't aware we did!
>>
>> In that case - sure, that is probably the more sensible solution.
>> Does it emulate SCMI?
>>
>
> The purpose of the SBSA/SBBR qemu machine is prototyping the
> interactions between rich firmware and the OS for things like RAS,
> secure variable storage for UEFI or capsule update.
>
> 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.

For firmware prototype development, CPU number and memory size may not
key points.
But from QEMU platform implementation point of view, they can not be
out of scope, they should be passed by command parameters instead,
because we don't know which numbers suit for users (although there are
default values).

>From the previous discussion, SBSA machine doesn't supply ACPI, as to
DT, implicit conclusion was same as ACPI: supplied by firmware.
That is why I had the question,  if QEMU doesn't supply DT, if memory
size and CPU number are passed by parameters dynamically, then how can
they be passed to guest firmware and OS, so I considered to keep as
least necessary DT nodes such as memory size, and also learned how
firmware does it on real hardware, to see if we can completely remove
all DT nodes.

You support to keep DT as virt, it is really fine with me, but this
triggers how my patch look like:
If no DT in SBSA machine, then the code had much more difference with
virt, so there is possibility to make it a simple separate file;
If keep same DT as virt, then there are more overlap with virt codes,
so I am not sure how the patch should like finally, I still prefer
separate file to keep virt untouched, but not sure if others would
suggest to extract common codes to a third file, it is up to the
maintainer and reviewers.

So, keeping DT same as virt is final choice, right?
And how the patch look like? or I send a v3 with separate file to see
for discuss?
(understand sometime people cannot / don't like to give comments
without seeing the patch)

>
> 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.
>
> At some point, it would be nice if we could get UEFI to receive its
> platform description from ARM-TF in a generic manner, and it would be
> good for EDK2 and ARM-TF to align on this. So even if we decide that
> SCMI is more suitable way to convey this information from QEMU to the
> guest firmware, I would object to implementing the client side of that
> in UEFI, given that it should be ARM-TF that provides this
> information.