Re: [PATCH v8 07/10] hw/arm/sbsa-ref: add ITS support in SBSA GIC

[Peter Maydell]

On Fri, 15 Oct 2021 at 13:23, Leif Lindholm <leif@nuviainc.com> wrote:
> (Apologies for delay. Alex also tells me you are currently away, but
> there is no strong urgency here.)

(Thanks for the ping via Alex -- I missed this email when I was
scanning through my qemu-devel mail backlog after my holiday...)

> On Thu, Sep 23, 2021 at 17:00:35 +0100, Peter Maydell wrote:
> > Leif, what's your plan/preferences here ?
>
> I discussed this with Alex/Shashi.
>
> One further complicating aspect is that the EDK2 GIC driver currently
> relies on GIC addresses being known at compile-time.
>
> > Presumably somebody also needs to do the system-software side
> > of things to handle the ITS being present and the redistributor
> > frames moving...
>
> Since it *would* be useful to get this support in, I think the most
> pragmatic plan would be:
> - Add ITS in the location originally proposed by Shashi.
> - Add information to DT:
>   - Platform version (1).
>   - GICD, GICR, and ITS base addresses.
> - edk2: Convert GIC driver to support dynamic block addresses.
> - TF-A: Parse the DT and add SIP SVC calls:
>   - to retrieve it (or return not supported if not found).
>   - to retrieve base addresses for GICD, GICR, and ITS.
> - edk2-platforms: Query TF-A for platform version.
>   If platform version >= 1, request base addresses for GICD, GICR, and
>   ITS.
>   - Generate IORT if ITS present.
> - Update GIC frame layout to match an ARM GIC-?00. (Platform version 2)
>
> Unrelated to the ITS question, and not requiring any intervention on
> the QEMU side, we can then also transition the CPU and DRAM discovery
> to SIP SVC calls, and stop sharing the DT with edk2 completely.
>
> And some way further down the line we could do the SCP thing, which
> would let us support different GIC-layouts/configurations based on
> platform command line options. (Platform version 3.)
> (TF-A makes SCP calls if version >= 3)
> This would then require no changes to edk2-platforms.

This sounds good to me.

> (Numeric values described as incrementing integer rather than trying
> to guess at specific qemu release numbers.)

This is kind of mixing up two separate things. The above describes
three "versions" of this machine type, which you might consider
as like revision A/B/C of hardware (and where firmware might for
instance read a 'board revision' register or something to tell
them apart). QEMU release numbers and versioned board types like virt-6.0
are a very specific thing that is taking on a guarantee about
maintaining version compatibility of the same board type between
different QEMU versions. We can make sbsa-ref a versioned machine
type in that sense if you really want to do it, but it makes future
changes to the machine rather more painful (everything new
immediately needs flags and properties and so on so that it can be
added only for newer versions of the machine type and not for the
old one -- at a rough count at least  10% of hw/arm/virt.c is purely
boilerplate and machinery for versioned machine types).
So it's not something we should do for sbsa-ref unless we have a good
reason I think.

-- PMM