On Sat, May 2, 2026 at 12:30 AM Peter Maydell <[email protected]> wrote: > > On Fri, 1 May 2026 at 15:02, Leif Lindholm > <[email protected]> wrote: > > > > On Fri, 1 May 2026 at 04:28, Alistair Francis <[email protected]> wrote: > > > The first line of the README says: > > > > > > """ > > > This document is capturing discussions at the Server Platform TG. > > > These are not official specifications and everything in this document > > > may change. > > > """
Ah, this was just ratified. So now there is a version 1.0 and no "this may change at any point" notice. > > > > > > So this machine needs to start out with version support (like the ARM > > > virt board) > > > > We ended up not doing that for sbsa-ref, partially based on advice > > from Peter (added to cc), > > which I can't right now bring to mind in any great detail. > > > > I would expect the same argument holds here. Peter? > > Roughly, QEMU versioned machine types are a big maintenance pain, > so we should only have them where the use-case is that users > really want to be able to run and migrate their workloads from > old QEMU to new QEMU. The use case for sbsa-ref is "I am developing > the full firmware/system software stack and I want a reference > platform for that" -- nobody wants to be able to run the older > version of the firmware/software stack on the newer QEMU, > and certainly nobody is going to be doing live migration of the > software between QEMU versions. The small population of people > doing this development work will be running the bleeding edge of > all the components involved anyway, and to the extent they care > about running on an older / newer QEMU for convenience they can > handle that in the firmware -- sbsa-ref passes the firmware a > "machine-version-major" and "machine-version-minor" that we > bump when we add something that would be a compat break with the > firmware. Now that the spec is ratified and this isn't expected to change weekly in user breaking ways I agree, thanks Peter Alistair
