[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