| Message ID | 20230103181646.55711-1-richard.henderson@linaro.org |
|---|---|
| Headers | show |
| Series | Toward class init of cpu features | expand |
On 1/3/23 10:16, Richard Henderson wrote: > Richard Henderson (40): > target/arm: Remove aarch64_cpu_finalizefn > target/arm: Create arm_cpu_register_parent > target/arm: Remove AArch64CPUClass > target/arm: Create TYPE_ARM_V7M_CPU ... > target/arm: Utilize arm-cpu instance_post_init hook ... > hw/arm/bcm2836: Set mp-affinity property in realize > target/arm: Rename arm_cpu_mp_affinity > target/arm: Create arm_cpu_mp_affinity > target/arm: Represent the entire MPIDR_EL1 I meant to say: Peter, at least this handfull of patches ought to be useful cleanup regardless of the rest of the series. r~
On Tue, 3 Jan 2023 at 18:27, Richard Henderson <richard.henderson@linaro.org> wrote: > The specific problem I'm trying to solve is the location and > representation of the coprocessor register hash table for ARM cpus, > but in the process affects how cpu initialization might be done for > all targets. > > At present, each cpu (for all targets) is initialized separately. > For some, like ARM, we apply QOM properties and then build a hash > table of all coprocessor regs that are valid for the cpu. For others, > like m68k and ppc, we build tables of all valid instructions > (ppc is slowly moving away from constructed tables to decodetree, > but the migration is not complete). > > Importantly, this happens N times for smp system emulation, for each > cpu instance, meaning we do N times the work on startup as necessary. > For system emulation this isn't so bad, as N is generally small-ish, > but it certainly could be improved. > > More importantly, this happens for each thread in user-only emulation. > This is much more significant because threads can be short-lived, and > there can be many hundreds of them, each one performing what amounts > to redundant initialization. > > The "obvious" solution is to make better use of the cpu class object. > Construct data structures once to be shared with all instances. 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. thanks -- PMM
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. If we were presented with the class properties early enough, we could create sub-classes with the desired properties before instantiating the objects that go with. Anyway, it seems like we ought to have some solution that does not involve repeating the same id register finalization + cpregs hash table construction per cpu -- especially for user-only. r~
On Fri, 6 Jan 2023 at 19:29, Richard Henderson <richard.henderson@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
On 1/6/23 13:59, Peter Maydell wrote: > 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. Yes indeed, but in all of those cases we want all of the cpus to act identically. Those are all easily handled (patches 35, 36, 38). > 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; If we find another thing that needs to be different between cpus, you mean? > and it becomes visible in user-facing command line stuff. No it doesn't -- command line is *not* affected, because both before and after, all properties are applied identically to all objects. QMP is affected, which is where I stopped and started asking questions about what QMP is actually trying to do. > 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. Eh, I didn't think it's particularly confusing as a concept. The code is rough, buy what one might expect from an RFC. We really ought to have *some* solution to not repeating property + feature + isar interpretation on a per-cpu basis. I'd be delighted to hear alternatives. r~
Peter Maydell <peter.maydell@linaro.org> writes: > On Fri, 6 Jan 2023 at 19:29, Richard Henderson > <richard.henderson@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. What about cloning objects after they are realised? After all that is what we do for the core CPUClass in user-mode. > > thanks > -- PMM
On 1/6/23 15:43, Alex Bennée wrote: > What about cloning objects after they are realised? After all that is > what we do for the core CPUClass in user-mode. No we don't. Where do you get that idea? r~
Richard Henderson <richard.henderson@linaro.org> writes: > On 1/6/23 15:43, Alex Bennée wrote: >> What about cloning objects after they are realised? After all that is >> what we do for the core CPUClass in user-mode. > > No we don't. Where do you get that idea? Well linux-user does cpu_copy which involves a create step followed by a reset and then a bunch of copying state across. Can we assume all CPUs get reset before they are actively used? Would it be too hacky to defer the creation of those hash tables to the reset phase and skip it if already defined?
On Fri, 6 Jan 2023 at 22:28, Richard Henderson <richard.henderson@linaro.org> wrote: > > On 1/6/23 13:59, Peter Maydell wrote: > > 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. > > Yes indeed, but in all of those cases we want all of the cpus to act identically. Those > are all easily handled (patches 35, 36, 38). That's just a happenstance of how the boards create them. There's no inherent reason that every CPU of a particular type in the system has to have identical properties. > > 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; > > If we find another thing that needs to be different between cpus, you mean? Yes. But conceptually we already have lots of those, we just happen not to be using them right this instant. > > 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. > > Eh, I didn't think it's particularly confusing as a concept. > The code is rough, buy what one might expect from an RFC. > > We really ought to have *some* solution to not repeating property + feature + isar > interpretation on a per-cpu basis. I'd be delighted to hear alternatives. Hash "cpu type plus property settings plus ID registers", and look them up to see if we've already created the cpregs hashtable for an existing CPU? -- PMM
On 1/7/23 02:19, Alex Bennée wrote: > > Richard Henderson <richard.henderson@linaro.org> writes: > >> On 1/6/23 15:43, Alex Bennée wrote: >>> What about cloning objects after they are realised? After all that is >>> what we do for the core CPUClass in user-mode. >> >> No we don't. Where do you get that idea? > > Well linux-user does cpu_copy which involves a create step followed by a > reset and then a bunch of copying state across. Can we assume all CPUs > get reset before they are actively used? The hash table creation happens during qdev_realize, there in cpu_create. > Would it be too hacky to defer the creation of those hash tables to the > reset phase and skip it if already defined? Even then you have the copy after the reset, so no, that won't work. r~