qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 3/3] exec.c: Collect AddressSpace related fie


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2 3/3] exec.c: Collect AddressSpace related fields into a CPUAddressSpace struct
Date: Wed, 7 Oct 2015 22:13:42 +0100

On 7 October 2015 at 10:57, Richard Henderson <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]