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

[Leif Lindholm <leif@nuviainc.com>]

On Tue, Nov 09, 2021 at 21:21:46 +0000, Peter Maydell wrote:
> > 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.

Right. So my preference is to communicate the version only, and then
have that version let firmware know whether there are now other
interfaces available (i.e. an SCP) to gather additional system
information.

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

I'm leaning towards (1), at least while working towards a "complete"
platform (when we may still add/change features, but not how those
features are communicated to the firmware).

Once the platform is complete, I would very much want to
support (3), for example to tweak GIC layout to match GIC-600 or
GIC-700, with different configurations.

/
     Leif