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

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Leif Lindholm <leif.lindholm@linaro.org>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Hongbo Zhang" <hongbo.zhang@linaro.org>,
	"Andrew Jones" <drjones@redhat.com>,
	"Radoslaw Biernacki" <radoslaw.biernacki@linaro.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	qemu-arm <qemu-arm@nongnu.org>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise machine type
Date: Thu, 30 Aug 2018 15:29:02 +0200	[thread overview]
Message-ID: <CAKv+Gu9r+1OBOSUBW_KpDEEoKyc=iwW4zVEe04-_JUnJtSGupQ@mail.gmail.com> (raw)
In-Reply-To: <20180830100233.nr6fm3npy57zl4xx@bivouac.eciton.net>

On 30 August 2018 at 12:02, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> On Thu, Aug 30, 2018 at 09:39:33AM +0100, Peter Maydell wrote:
>> On 30 August 2018 at 09:31, Leif Lindholm <leif.lindholm@linaro.org> 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.

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.