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: Peter Maydell
Subject: Re: Trying to understand QOM object creation and property linking
Date: Thu, 6 Jan 2022 15:04:13 +0000

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.

> So I guess I just have to repeat the creation of the aliases for each
> core. This seems needlessly messy...

It's not great, but the MR tree does need each MR to have only
one parent. Maybe there's some way to make it a bit less tedious
to create the aliases.

-- PMM



reply via email to

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