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

[Peter Maydell <peter.maydell@linaro.org>]

On Thu, 2 Sept 2021 at 13:43, Leif Lindholm <leif@nuviainc.com> wrote:
> On Thu, Aug 19, 2021 at 14:27:19 +0100, Peter Maydell wrote:
> > If you want a command line switch to let the user say whether the
> > ITS should be present or not, you should use the same thing the
> > virt board does, which is a bool property "its".
> >
> > If you want the sbsa-ref board to become a proper "versioned machine
> > type" such that users can say "-M sbsa-ref-6.1" and get the SBSA
> > board exactly as QEMU 6.1 supplied it, that looks completely different
> > (and is a heavy back-compatibility burden, so needs discussion about
> > whether now is the right time to do it), and probably is better not
> > tangled up with this patchseries.
>
> Hmm. I mean, you're absolutely right about the complexity and need for
> discussion. My concern is that we cannot insert the ITS block in the
> memory map where it would be in an ARM GIC implementation without
> changing the memory map (pushing the redistributor further down).
>
> It is also true that simply versioning sbsa-ref does not mean we end
> up with a properly aligned with ARM IP register frame layout. Some
> additional logic is required for that.
>
> If we assume that we don't want to further complicate this set by
> adding the additional logic *now*, I see three options:
> - Implement memory map versioning for sbsa-ref for this set, placing
>   the ITS (if enabled) directly after the DIST for sbsa-ref-6.2.
> - In this set, place the ITS frames in a different location relative
>   to the REDIST frames than it will end up once the further logic is
>   implemented.
> - Drop the sbsa-ref ITS support from this set, and bring it in with
>   the set implementing the additional logic.

I don't think implementing versioned machine types helps you much
anyway, because your users are all going to be currently using
-M sbsa-ref, so they will by default see the change in device layout.

I do think that we should get the "with an ITS" device layout right
from the start, so that we're only dealing with 2 possibilities
(what we have today, and the final intended layout), not 3 (today,
final layout, some intermediate thing).

How does guest software on this board figure out the memory
layout ? Is there a mechanism for telling it "this is version 2
of this board" ?

-- PMM