qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [PATCH v8 07/10] hw/arm/sbsa-ref: add ITS support in SBSA GIC
Date: Thu, 11 Nov 2021 16:55:09 +0000

On Tue, 9 Nov 2021 at 22:52, Leif Lindholm <leif@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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]