qemu-devel
[Top][All Lists]
Advanced

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

Re: Trying to understand QOM object creation and property linking


From: Alex Bennée
Subject: Re: Trying to understand QOM object creation and property linking
Date: Thu, 06 Jan 2022 15:44:26 +0000
User-agent: mu4e 1.7.5; emacs 28.0.90

Peter Maydell <peter.maydell@linaro.org> writes:

> On Thu, 6 Jan 2022 at 14:26, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>> > On Wed, 5 Jan 2022 at 21:05, Alex Bennée <alex.bennee@linaro.org> wrote:
>> >> Can't be added as a subregion to the container...
>> >>
>> >>   qemu-system-arm: ../../softmmu/memory.c:2538: 
>> >> memory_region_add_subregion_common: Assertion `!subregion->container' 
>> >> failed.
>> >
>> > This assert means you tried to add the same MemoryRegion
>> > as a subregion of more than one parent MR.
>>
>> Right - that is probably something we should make (more?) explicitly
>> clear in the Memory API docs.
>
> The doc comment does document the requirement:
>  * [...] A region
>  * may only be added once as a subregion (unless removed with
>  * memory_region_del_subregion()); use memory_region_init_alias() if you
>  * want a region to be a subregion in multiple locations.
>
> One of the deficiencies of C assert() is the lack of an
> explanatory text message to go along with the raw expression.
>
>> > You can either:
>> >  * pass all the CPUs the same container as their "memory" link,
>> >    if they all see the same view of the world
>>
>> This should be the case - I don't think the different cores have any
>> particular different view of the world. The use of the two 4kb banks I
>> think is purely convention.
>>
>> However trying for a single container shared between both cores fails
>> because armv7m_realize adds it's board_memory to another container:
>>
>>     memory_region_add_subregion_overlap(&s->container, 0, s->board_memory, 
>> -1);
>
> Yeah, that trick only works for the real CPU object, not for
> passing to SoC or SoC-like objects.

Hmm I wonder if I should be instantiating the underlying CPU object?
AIUI the cores are cortex-m0+ so I assume that comes with the gic/irq
wiring up that armv7m does?

-- 
Alex Bennée



reply via email to

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