[v1,00/12] arm: Add first models of Xilinx Versal SoC

From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>

This patch series adds initial support for Xilinx's Versal SoC.
Xilinx is introducing Versal, an adaptive compute acceleration platform
(ACAP), built on 7nm FinFET process technology. Versal ACAPs combine Scalar
Processing Engines, Adaptable Hardware Engines, and Intelligent Engines with
leading-edge memory and interfacing technologies to deliver powerful
heterogeneous acceleration for any application. The Versal AI Core series has
five devices, offering 128 to 400 AI Engines. The series includes dual-core Arm
Cortex-A72 application processors, dual-core Arm Cortex-R5 real-time
processors, 256KB of on-chip memory with ECC, more than 1,900 DSP engines
optimized for high-precision floating point with low latency.

More info can be found here:
https://www.xilinx.com/news/press/2018/xilinx-unveils-versal-the-first-in-a-new-category-of-platforms-delivering-rapid-innovation-with-software-programmability-and-scalable-ai-inference.html


In QEMU we'd like to have a virtual developer board with the Versal SoC
and a selected set of peripherals under the control of QEMU.
We'd like to gradually extend this board as QEMU gains more support
for Versal hardware components. QEMU will generate a device-tree
describing only the components it supports and includes in the virtual
dev board.

Before adding Versal support, this series starts with a few fixes to the
GEM that I ran into when running recent kernels on the Versal and ZynqMP
models.

I also noticed a problem with HVC insns not being enabled when using
QEMU's PSCI implementation on CPU's with EL2 and EL3 enabled. This causes
problems for Linux/KVM guests, also fixed in this series.

Best regards,
Edgar

Edgar E. Iglesias (12):
  net: cadence_gem: Disable TSU feature bit
  net: cadence_gem: Announce availability of priority queues
  net: cadence_gem: Use uint32_t for 32bit descriptor words
  net: cadence_gem: Add macro with max number of descriptor words
  net: cadence_gem: Add support for extended descriptors
  net: cadence_gem: Add support for selecting the DMA MemoryRegion
  net: cadence_gem: Implement support for 64bit descriptor addresses
  net: cadence_gem: Announce 64bit addressing support
  target-arm: powerctl: Enable HVC when starting CPUs to EL2
  target/arm: Add the Cortex-A72
  hw/arm: versal: Add a model of Xilinx Versal SoC
  hw/arm: versal: Add a virtual Xilinx Versal board

 default-configs/aarch64-softmmu.mak |   1 +
 hw/arm/Makefile.objs                |   1 +
 hw/arm/xlnx-versal-virt.c           | 494 ++++++++++++++++++++++++++++++++++++
 hw/arm/xlnx-versal.c                | 339 +++++++++++++++++++++++++
 hw/net/cadence_gem.c                | 196 ++++++++++----
 include/hw/arm/xlnx-versal.h        | 122 +++++++++
 include/hw/net/cadence_gem.h        |   7 +-
 target/arm/arm-powerctl.c           |  11 +
 target/arm/cpu64.c                  |  59 +++++
 9 files changed, 1175 insertions(+), 55 deletions(-)
 create mode 100644 hw/arm/xlnx-versal-virt.c
 create mode 100644 hw/arm/xlnx-versal.c
 create mode 100644 include/hw/arm/xlnx-versal.h

On 3 October 2018 at 16:07, Edgar E. Iglesias <edgar.iglesias@gmail.com> wrote:
> In QEMU we'd like to have a virtual developer board with the Versal SoC
> and a selected set of peripherals under the control of QEMU.
> We'd like to gradually extend this board as QEMU gains more support
> for Versal hardware components. QEMU will generate a device-tree
> describing only the components it supports and includes in the virtual
> dev board.

So, the SoC implementation and the GEM and HVC bugfix patches
here are straightforward. What I'm less sure about is the "virtual"
nature of the board model. What do we gain doing this rather than
just modelling some particular Versal dev board?

At the moment we have a fairly clear distinction:
 * most machine models are models of real hardware, and the
   real hardware is the litmus test for how things are supposed
   to work (and, like real hardware, the user provides the DTB)
 * the "virt" board is special, because it is purely virtual and
   contains only a few specific devices, so it can run Linux guests

This would seem to be an odd hybrid, with an SoC that's a model
of real hardware but also some virtual "QEMU controls what's
present and creates the dtb" aspects.

thanks
-- PMM

On Mon, Oct 08, 2018 at 03:08:14PM +0100, Peter Maydell wrote:
> On 3 October 2018 at 16:07, Edgar E. Iglesias <edgar.iglesias@gmail.com> wrote:
> > In QEMU we'd like to have a virtual developer board with the Versal SoC
> > and a selected set of peripherals under the control of QEMU.
> > We'd like to gradually extend this board as QEMU gains more support
> > for Versal hardware components. QEMU will generate a device-tree
> > describing only the components it supports and includes in the virtual
> > dev board.
> 
> So, the SoC implementation and the GEM and HVC bugfix patches
> here are straightforward. What I'm less sure about is the "virtual"
> nature of the board model. What do we gain doing this rather than
> just modelling some particular Versal dev board?
> 
> At the moment we have a fairly clear distinction:
>  * most machine models are models of real hardware, and the
>    real hardware is the litmus test for how things are supposed
>    to work (and, like real hardware, the user provides the DTB)
>  * the "virt" board is special, because it is purely virtual and
>    contains only a few specific devices, so it can run Linux guests
> 
> This would seem to be an odd hybrid, with an SoC that's a model
> of real hardware but also some virtual "QEMU controls what's
> present and creates the dtb" aspects.


Hi Peter,

This is a good question.

There're a few issues we see that we think this approach will help to solve
or at least mitigate.

The Versal architecture will be a family of chips (same as ZynqMP). Each
tapeout and board comes with a set of physical limitations. I.e due to
size/power/heat and other constraints not everything that the architecture
has can be available everywhere. For example a specific board may only
enable one GEM.

We'd like to have a QEMU board that doesn't get limited by these physical
constrains but instead, with time, can grow to the full potential even
though there may not be tapeouts nor boards at this given point in time
that have it all.

Another problem that we've seen with the ZynqMP is that users struggle
to run stuff on QEMU because we don't support the full set of devices
needed to run everything that you can run on a real board. So we need
to create "QEMU" device-trees that contain the subset that QEMU supports.
These dtbs then float around and mixing and matching versions becomes a problem.
If QEMU generates the a device tree on the fly, we hope to avoid that
problem. Note that this board still accepts a dtb on the command-line if
users really want to pass one.


At the moment, Versal only exists in FPGA based emulation boards.
These implementations are flexible in that different configurations can
be re-programmed onto the FPGAs at any time.
From my perspective, the name of the board is not so important. We can
call it Xilinx Versal QEMU Developer board, Xilinx Versal Emulation Board,
or what ever but it would be nice to keep the characteristics of an
phsyically unconstrained board and the auto-generated device-tree.

I hope that clarifies the intent.

Thanks and Best regards,
Edgar