Re: [RFC PATCH 00/40] Toward class init of cpu features

2023-01-07 Thread Richard Henderson
On 1/7/23 02:19, Alex Bennée wrote: Richard Henderson 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

Re: [RFC PATCH 00/40] Toward class init of cpu features

2023-01-07 Thread Peter Maydell
On Fri, 6 Jan 2023 at 22:28, Richard Henderson 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

Re: [RFC PATCH 00/40] Toward class init of cpu features

2023-01-07 Thread Alex Bennée
Richard Henderson 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

Re: [RFC PATCH 00/40] Toward class init of cpu features

2023-01-06 Thread Richard Henderson
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~

Re: [RFC PATCH 00/40] Toward class init of cpu features

2023-01-06 Thread Alex Bennée
Peter Maydell writes: > On Fri, 6 Jan 2023 at 19:29, Richard Henderson > 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)

Re: [RFC PATCH 00/40] Toward class init of cpu features

2023-01-06 Thread Richard Henderson
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

Re: [RFC PATCH 00/40] Toward class init of cpu features

2023-01-06 Thread Peter Maydell
On Fri, 6 Jan 2023 at 19:29, Richard Henderson 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 > >

Re: [RFC PATCH 00/40] Toward class init of cpu features

2023-01-06 Thread Richard Henderson
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

Re: [RFC PATCH 00/40] Toward class init of cpu features

2023-01-06 Thread Peter Maydell
On Tue, 3 Jan 2023 at 18:27, Richard Henderson 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

Re: [RFC PATCH 00/40] Toward class init of cpu features

2023-01-03 Thread Richard Henderson
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

[RFC PATCH 00/40] Toward class init of cpu features

2023-01-03 Thread Richard Henderson
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,