On Fri, 6 Jan 2023 at 19:29, Richard Henderson <richard.hender...@linaro.org> wrote: > > On 1/6/23 11:12, Peter Maydell wrote: > > The trouble with this idea is that not all instances of the same > > class are actually necessarily the same. For instance, if you > > have a system with both (a) a Cortex-A53 with a PMU, and > > (b) a Cortex-A53 without a PMU, then they're both instances of > > the same class, but they shouldn't be sharing the coprocessor > > register hashtable because they don't have an identical set of > > system registers. > > > > This kind of same-CPU-type-heterogenous-configuration system is > > not something we're currently using on A-profile, but we do have > > it for M-profile (the sse200 has a dual-core setup where only one > > of the CPUs has an FPU), so it's not totally outlandish. > > Yes, I know. See patch 29 where I moved the vfp and dsp properties off of > the m-profile > cpus and created new cpu classes instead, specifically for the sse220. > > It's not scalable, I'll grant you, but it's hard to design for something > we're not using. > What we use now, apart from the sse200, are common properties set on the > command-line.
We also set some properties in code -- eg aspeed_ast2600.c clears the 'neon' property on its CPUs, lots of the boards clear has_el3 and has_el2, etc. I hadn't got as far as patch 29, but looking at it now that looks like a pretty strong indication that this is the wrong way to go. It creates 3 extra cortex-m33 CPU classes, and if we find another thing that ought to be a CPU property then we'll be up to 8; and the mess propagates up into the SSE-200 class, which is also no longer able to be configured in the normal way by setting properties on it, and it becomes visible in user-facing command line stuff. I think our object model pretty strongly wants "create object; set properties on it that only affect this object you created; realize it", and having one particular subset of objects that doesn't work the same way is going to be very confusing. thanks -- PMM
