qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 02/16] exec.c: Allow target CPUs to define multi


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 02/16] exec.c: Allow target CPUs to define multiple AddressSpaces
Date: Fri, 6 Nov 2015 13:34:44 +0000

On 6 November 2015 at 13:21, Edgar E. Iglesias <address@hidden> wrote:
> On Thu, Nov 05, 2015 at 06:15:44PM +0000, Peter Maydell wrote:
>> Allow multiple calls to cpu_address_space_init(); each
>> call adds an entry to the cpu->ases array at the specified
>> index. It is up to the target-specific CPU code to actually use
>> these extra address spaces.
>>
>> Since this multiple AddressSpace support won't work with
>> KVM, add an assertion to avoid confusing failures.
>>
>> Signed-off-by: Peter Maydell <address@hidden>

>> +    if (asidx >= cpu->num_ases) {
>> +        if (cpu->num_ases == 0) {
>> +            cpu->cpu_ases = g_new(CPUAddressSpace, asidx + 1);
>> +        } else {
>> +            cpu->cpu_ases = g_renew(CPUAddressSpace, cpu->cpu_ases, asidx + 
>> 1);
>
> IIUC, g_renew may move the entire cpu_ases area. The internals of
> memory_listener_register (called below) seem to put away the pointers to 
> listeners
> so a renew+move would leave invalid pointers to listeners in memory.c 
> wouldn't it?
>
> There are various ways of solving this, (e.g dynamic allocation of the 
> listener,
> static allocation of the cpu_ases, invalidate all listeners and restore them 
> after
> each as init and more). I'm sure you'll figure something out.

Oops, yes, you're right.

Maybe we should just have the target CPU say in advance what the
maximum number of AddressSpaces it will have is -- my expectation
is that this will be (a) small (b) known in advance anyway.

thanks
-- PMM



reply via email to

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