On Tue, Nov 09, 2021 at 13:43:50 +0000, Peter Maydell wrote:
> On Fri, 15 Oct 2021 at 13:23, Leif Lindholm <l...@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.
Hmm, right. So you're thinking containing the versioning fully in the
interfaces presented by the model:
- Is the version node present?
- If so, is it greater than X?
- If so, is it great enough to support the SCP interface?
And let the firmware deal with that?
I was kind of thinking it was expected for incompatible machine
versions to be qemu versioned. But I'm good with skipping that bit if
it's not.
/
Leif
