On 7 October 2015 at 10:57, Richard Henderson <r...@twiddle.net> wrote: > On 10/02/2015 12:29 AM, Peter Maydell wrote: >> >> + cpu->cpu_ases = g_new0(CPUAddressSpace, 1); >> + cpu->cpu_ases[0].cpu = cpu; >> + cpu->cpu_ases[0].as = as; >> + cpu->cpu_ases[0].tcg_as_listener.commit = tcg_commit; >> + memory_listener_register(&cpu->cpu_ases[0].tcg_as_listener, as); >> } > > > What's the plan when it's more than one?
We g_realloc() the array to make it larger if the target-specific code calls us again to add another AS. > Just thinking about why separate allocation vs embedding an array. Though > possibly with the CPUState member being a pointer to an array within the > TargetCPUClass, or CPUTargetState. Dunno. An embedded array runs you into the problem that cpu.h doesn't have access to a definition of the MemoryListener struct (at least I think it's that one), so it doesn't know how much space to allocate in the structure. Plus MemoryListener doesn't exist in non-softmmu configs, and allowing the CPUState struct to be different sizes for softmmu vs not doesn't work because the header can be used from compiled-once-only .c files. This awkwardness is why we ended up with CPUState having a pointer to a MemoryListener and thus the loop in tcg_commit in the first place. thanks -- PMM
