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

[Peter Maydell <peter.maydell@linaro.org>]

On Tue, 9 Nov 2021 at 20:42, Leif Lindholm <leif@nuviainc.com> wrote:
>
> On Tue, Nov 09, 2021 at 13:43:50 +0000, Peter Maydell wrote:
> > 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:
> > > (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?

How the model tells the firmware about the presence/absence of
certain things and whether it's one version or another is
a different question again :-) I guess since we're using DTB
already for passing some info to the firmware that that would be
the way to continue. Whether it's better to have a simple
"version" node or property, or to have perhaps distinct things
in the DTB to indicate presence/absence of important features I
don't know and leave up to you.

> 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.

The other thing we should nail down is how the user is going to
select which flavour of machine they want to provide. Three
options:
 (1) no control, QEMU just emulates whatever the newest flavour is.
User needs to go find a firmware image new enough to cope.
 (2) different flavours exposed as different machine types
(analogous to how we have musca-a and musca-b1, or raspi3ap and
raspi3b, for instance). Old user command lines keep working
because -M sbsa-ref doesn't change; the new stuff would be
available via -M sbsa-ref-2 or whatever.
 (3) different flavours exposed via a property
(so you would have -M sbsa-ref,machine-revision=2 or something).
If the revision defaults to 1 then old user setups still work
but everybody starts to have to cart around an extra command
line argument. If it defaults to "newest we know about" you
get the opposite set of tradeoffs.

-- PMM