On Thu, Sep 02, 2021 at 13:51:26 +0100, Peter Maydell wrote: > On Thu, 2 Sept 2021 at 13:43, Leif Lindholm <l...@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" ?
Not currently. Aiming to look like most SBSA platforms, it is hard-wired, and firmware passes that information to the os. This is the kind of thing I eventually want to do using a PV-model SCP. As a stop-gap, we could push it through the DT, like we do for cpus and memory? / Leif