All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Eduardo Habkost" <eduardo@habkost.net>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	qemu-devel@nongnu.org
Subject: Re: Trying to understand QOM object creation and property linking
Date: Thu, 06 Jan 2022 14:20:32 +0000	[thread overview]
Message-ID: <87iluxhrdc.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA9XX26RHmNM59Zc13dwvhv83bAnomLp7Yj45Wmf16W66w@mail.gmail.com>


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.

> 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);

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

>  * if they have different views of the world, you need to
>    create a container for each CPU to be the "memory" link,
>    and to populate that container you need to create N-1 alias MRs
>    of the board_memory MR (CPU 0's container can use the original
>    board_memory MR; CPU 1, ... use the aliases).
>
> Example of option 1: virt board
> Example of option 2: hw/arm/armsse.c (look at what it does with
> the s->cpu_container[] and s->container_alias[] arrays)
>
> -- PMM


-- 
Alex Bennée


  reply	other threads:[~2022-01-06 14:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-05 18:03 Trying to understand QOM object creation and property linking Alex Bennée
2022-01-05 19:03 ` Philippe Mathieu-Daudé
2022-01-05 21:02   ` Alex Bennée
2022-01-06 11:16     ` Peter Maydell
2022-01-06 14:20       ` Alex Bennée [this message]
2022-01-06 15:04         ` Peter Maydell
2022-01-06 15:44           ` Alex Bennée
2022-01-06 15:52             ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87iluxhrdc.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=berrange@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=f4bug@amsat.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.