Re: [PATCH] hw/arm: add versioning to sbsa-ref machine DT

[Leif Lindholm]

Hi Cedric,

On Thu, Apr 28, 2022 at 10:55:54 +0200, Cédric Le Goater wrote:
> > The sbsa-ref machine is continuously evolving. Some of the changes we
> > want to make in the near future, to align with real components (e.g.
> > the GIC-700), will break compatibility for existing firmware.
> > 
> > Introduce two new properties to the DT generated on machine generation:
> > - machine-version-major
> >    To be incremented when a platform change makes the machine
> >    incompatible with existing firmware.
> > - machine-version-minor
> >    To be incremented when functionality is added to the machine
> >    without causing incompatibility with existing firmware.
> >    to be reset to 0 when machine-version-major is incremented.
> > 
> > These properties are both introduced with the value 0.
> > (Hence, a machine where the DT is lacking these nodes is equivalent
> > to version 0.0.)
> 
> This raises a lot of questions. I am talking with my PAPR specs
> experience there, which might be off topic for SBSA, but it's a
> way to clarify my understanding.

That is a reasonable assumption: you may expect the ARM platform
specifications to usefully describe a general platform which sofware
can be developed against. However, they are not. They describe the
absolute minimum that it is even theoretically possible to develop
portable software against.

> If we need to introduce incompatible changes in the sbsa machine,
> that would break existing firmwares, I think we should start versioning
> the sbsa machine like the other do : arm/i440fx/m68k/q35/s390x/spapr
> and add class attributes describing features being activated or not.
> This to make sure that firmware already shipped can always be run.

The versioning I'm introducing here is a separate one from the SBSA
numbering. See this thread for some history:

https://lore.kernel.org/qemu-devel/20211015122351.vc55mwzjbevl6wjy@leviathan/

Without derailing this thread too much, I will add that trying to
align a machine against specific SBSA versions is tricky, since ARM do
not put enough resource into QEMU development to keep up with
architectural feature support. ARM's strategy for that sort of thing
relies on proprietary software models.

It *would* be possible to retroactively add support for older
versions as the qemu feature set catches up, but that would be a
separate versioning scheme, mostly orhogonal with this one.
If ARM *did* start shifting to a focus on getting QEMU enablement done
in sync with architectural evolution, the versioning scheme would
remain mostly orthogonal.

> Regarding the DT changes, we could also expose/advertise the new
> platform features by name with property nodes.

That would defeat the purpose of this platform, which is to serve as a
realistic target for developing SBBR firmware against. That we used a
DT at all to communicate information about the machine configuration
was in hindsight possibly a mistake, since it frequently leads to this
misunderstanding - but I opted for it in order to avoid inventing a
new data encapsulation format *only* for avoiding this topic popping
up at a regular cadence.

> What about the SBSA specs ? Do they need a change ? It is true that
> there are a bit vague regarding the DT, only referencing the Arm

DT is not relevant for ServerReady SR (which is what SBSA got renamed
to). There are embedded profiles defined by the ServerReady documents
that mention DT. Support for those, if anyone is interested in
creating/maintaining them, would be handled by a separate machine type.

Regards,

Leif