Re: [Qemu-devel] [PATCH v13 13/19] i.MX: KZM now uses the standalone i.MX31 SOC support

[Jean-Christophe DUBOIS <jcd@tribudubois.net>]

[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]

Le 10/08/2015 18:23, Peter Maydell a écrit :
> On 10 August 2015 at 17:15, Jean-Christophe DUBOIS <jcd@tribudubois.net> wrote:
>> Le 07/08/2015 15:45, Peter Maydell a écrit :
>>
>> On 16 July 2015 at 22:21, Jean-Christophe Dubois <jcd@tribudubois.net>
>> wrote:
>> memory_region_allocate_system_memory() needs to be called once and
>> only once by a board init. You're going to end up calling it twice here.
>>
>>
>> Actually, I may be calling it up 3 time because there is also an internal
>> (16KB) memory range that is allocated during the SOC init (fsl-imx31.c
>> file).
> Small blocks of stuff like 16KB are not the "main lump of RAM", so
> should not be initialized with memory_region_allocate_system_memory().
> Use memory_region_init_ram() followed by vmstate_register_ram_global()
> for that sort of small RAM region.

OK, I'll do it but it seems to me that in our case 
memory_region_allocate_system_memory() basically do:

  * memory_region_init_ram()
  * vmstate_register_ram_global()

>
>> Now as my memory (the 3 memory banks) is  (partially) discontiguous how am I
>> suppose to init all of it in one call?
> Your main RAM will be all contiguous, the only reason it would be
> discontiguous is if you were trying to model 128MB + 128MB,
> which you can't specify anyway with a single 'this much memory' ram_size
> argument.

Yes, It will make things a little more complex for the alias memory (if 
any).
I'll work something up.

>
>> And if memory_region_allocate_system_memory() should really be called only
>> once, why is it not enforced in this function? After all,
>> memory_region_allocate_system_memory() only calls memory_region_init_ram()
>> and vmstate_register_ram_global() in one step ...
> It does a lot more complicated things than that, potentially.

For NUMA platforms, it seems. But in our simple case it seems that it 
doesn't do a lot more. But OK, I'll change things.

> I agree that it ought to assert the once-and-only-once property;
> in fact I suggested on IRC last week that that would be a good
> plan, since it's an easy mistake to make.
>
> thanks
> -- PMM
>


[-- Attachment #2: Type: text/html, Size: 3694 bytes --]