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
