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

[Andrew Jones]

On Wed, Sep 05, 2018 at 06:08:57PM +0800, Hongbo Zhang wrote:
> 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.
> 
> Ard, we need to clarify which DT nodes should be kept in SBSA-ref QEMU.
> I've researched and tested, there are 3 kinds of DT nodes in the
> current 'virt' machine:
> 
> a) CPU DT node, because it is dynamic according to input parameters,
> and we don't want to get it by other way, so we agreed to keep it.

I have a patch series on the list[*] (which I need to refresh) that
would also add a generated cpu-map node. I think the SBSA-ref machine
may be interested in testing more complex cpu topologies, but that won't
be easy to do with ACPI boot guests unless the topology is hard coded.
How will sbsa-ref know when it should use a hard coded cpu topology vs.
a dynamic number of cpus in a flat topology?

[*] http://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg01170.html

> b) GIC, UART, Timer (and RTC?) nodes, these nodes are now used by
> UEFI, if removed, UEFI needs a rework to not rely on them any longer.

Will sbsa-ref support GICv2? If so, then timer and pmu DT nodes will
need to have their irqflags fields modified depending on the number of
configured CPUs.

> c) All the other devices nodes, such as GPIO, PCIE etc, currently the
> UEFI doesn't need them, so UEFI can boot with them removed.
> 
> How about b) and c)?
> my idea is to keep a) only, remove b) and thus a UEFI modification
> accordingly is to be done, c) can be removed freely.

So UEFI would learn to augment static DTBs with QEMU generated
DT nodes and/or other auxiliary info from QEMU passed to it
through the "guest DT" (which is now looking more like a guest
firmware configuration description)? Is it worth it? Why not
just require the entire DTB to be provided by the user on the
QEMU command line and completely ignore QEMU parameters like
'-smp'?

Thanks,
drew