On Tue, 9 Nov 2021 at 22:52, Leif Lindholm <l...@nuviainc.com> wrote: > > On Tue, Nov 09, 2021 at 21:21:46 +0000, Peter Maydell wrote: > > 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).
That's certainly the easiest on the QEMU side; you know the userbase so would know whether that kind of compat break is going to be OK with them. Q1: who is going to write the code for this? Q2: do we want to try to land "ITS in sbsa-ref" in 6.2? Given we're in freeze we're quite short of time even if we handwave the fact it's a new feature, not a bugfix, so I would lean towards 'no'... -- PMM
