On 10/08/2015 08:13 AM, Peter Maydell wrote:
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.
Ah, right. Thanks. Whole series
Reviewed-by: Richard Henderson <r...@twiddle.net>
r~
