From: Peter Xu <peterx@redhat.com>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Aleksandar Rikalo" <aleksandar.rikalo@syrmia.com>,
"Andrew Jeffery" <andrew@aj.id.au>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
qemu-devel@nongnu.org, "Laurent Vivier" <laurent@vivier.eu>,
"Alexander Bulekov" <alxndr@bu.edu>,
"Hervé Poussineau" <hpoussin@reactos.org>,
"Cédric Le Goater" <clg@kaod.org>,
"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Aurelien Jarno" <aurelien@aurel32.net>,
"Joel Stanley" <joel@jms.id.au>
Subject: Re: [PATCH 1/2] hw/mips/jazz: Use generic I/O bus via get_system_io()
Date: Thu, 11 Mar 2021 12:27:10 -0500 [thread overview]
Message-ID: <20210311172710.GH194839@xz-x1> (raw)
In-Reply-To: <a64ff8f0-5db1-c338-b99b-7a74a150a770@amsat.org>
On Thu, Mar 11, 2021 at 05:21:49PM +0100, Philippe Mathieu-Daudé wrote:
> +Aspeed team
>
> On 3/11/21 1:18 PM, Philippe Mathieu-Daudé wrote:
> > On 3/10/21 9:29 PM, Peter Xu wrote:
>
> >> Yeah no worry - it's just that I feel one memory_region_init_alias() call is
> >> probably missing in your huge series somewhere, so that you'll take that alias
> >> MR as subregion rather than the real MR (which is the root of one AS).
> >
> > OK, with your earlier comments start + Mark other comment I start
> > to understand better.
> >
> > So far:
> >
> > (1a) AddressSpace is a physical view, its base address must be zero
> >
> > (1b) AddressSpace aperture is fixed (depends on hardware design,
> > not changeable at runtime
> >
> > Therefore due to (1a):
> > (2) AddressSpace root MemoryRegion is a container and must not be
> > mmio-mapped anywhere (in particular not on SysBus).
> >
> > (3) If hardware has a MMIO view of an AddressSpace, it has to be
> > via a MemoryRegion alias. That way the alias handles paddr offset
> > adjustment to the zero-based AddressSpace root container MR.
> > Aliasing allows resizing the alias size without modifying the AS
> > aperture size (1b).
> >
> > I'll start adding assertions for (1a) and (2) in the code base and
> > see if (3) adjustments are required.
>
> So using:
>
> -- >8 --
> diff --git a/softmmu/memory.c b/softmmu/memory.c
> index 874a8fccdee..8ce2d7f83b9 100644
> --- a/softmmu/memory.c
> +++ b/softmmu/memory.c
> @@ -713,6 +713,12 @@ static MemoryRegion
> *memory_region_get_flatview_root(MemoryRegion *mr)
> continue;
> }
> }
> + if (mr && mr->addr) {
> + error_report("Detected flatview root memory region '%s' with"
> + " non-zero base address (0x%"HWADDR_PRIx"):
> aborting",
> + memory_region_name(mr), mr->addr);
> + abort();
> + }
>
> return mr;
> }
> ---
Maybe it works, but it looks a bit odd to test here. What I meant was
something like attached.
>
> I get:
>
> $ ./qemu-system-arm -M ast2600-evb
> qemu-system-arm: Detected flatview root memory region
> 'aspeed.fmc-ast2600.flash' with non-zero base address (0x20000000): aborting
> Aborted (core dumped)
>
> Indeed:
>
> $ ./qemu-system-arm -M ast2600-evb -S -monitor stdio
> QEMU 5.2.50 monitor - type 'help' for more information
> (qemu) info mtree
> address-space: dma-dram
> 0000000080000000-000000017fffffff (prio 0, i/o): aspeed-ram-container
> 0000000080000000-00000000bfffffff (prio 0, ram): ram
> 00000000c0000000-00000000ffffffff (prio 0, i/o): max_ram
>
> address-space: aspeed.fmc-ast2600-dma-flash
> 0000000020000000-000000002fffffff (prio 0, i/o): aspeed.fmc-ast2600.flash
> 0000000020000000-0000000027ffffff (prio 0, i/o): aspeed.fmc-ast2600.0
> 0000000028000000-000000002fffffff (prio 0, i/o): aspeed.fmc-ast2600.1
>
> address-space: aspeed.fmc-ast2600-dma-dram
> 0000000080000000-000000017fffffff (prio 0, i/o): aspeed-ram-container
> 0000000080000000-00000000bfffffff (prio 0, ram): ram
> 00000000c0000000-00000000ffffffff (prio 0, i/o): max_ram
>
> address-space: aspeed.spi1-ast2600-dma-flash
> 0000000030000000-000000003fffffff (prio 0, i/o): aspeed.spi1-ast2600.flash
> 0000000030000000-0000000037ffffff (prio 0, i/o): aspeed.spi1-ast2600.0
>
> address-space: aspeed.spi1-ast2600-dma-dram
> 0000000080000000-000000017fffffff (prio 0, i/o): aspeed-ram-container
> 0000000080000000-00000000bfffffff (prio 0, ram): ram
> 00000000c0000000-00000000ffffffff (prio 0, i/o): max_ram
>
> address-space: aspeed.spi2-ast2600-dma-flash
> 0000000050000000-000000005fffffff (prio 0, i/o): aspeed.spi2-ast2600.flash
> 0000000050000000-0000000057ffffff (prio 0, i/o): aspeed.spi2-ast2600.0
>
> address-space: aspeed.spi2-ast2600-dma-dram
> 0000000080000000-000000017fffffff (prio 0, i/o): aspeed-ram-container
> 0000000080000000-00000000bfffffff (prio 0, ram): ram
> 00000000c0000000-00000000ffffffff (prio 0, i/o): max_ram
>
> Many address spaces not zero-based...
Maybe it's still legal to make the root mr a subregion of another, so maybe I'm
completely wrong... then the patch attached won't make any sense either. It's
just that in my mind each MR should have a "parent" - for normal MR it's the
container MR, then for root MR it's easier to see the AS as its "parent".
Maybe Paolo could clarify this..
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2021-03-11 17:37 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-05 23:54 [PATCH 0/3] memory: Display AddressSpace zero-based in 'info mtree' Philippe Mathieu-Daudé
2021-03-05 23:54 ` [PATCH 1/3] memory: Better name 'offset' argument in mtree_print_mr() Philippe Mathieu-Daudé
2021-03-05 23:54 ` [PATCH 2/3] memory: Provide 'base address' argument to mtree_print_mr() Philippe Mathieu-Daudé
2021-03-08 23:40 ` Peter Xu
2021-03-09 9:39 ` Philippe Mathieu-Daudé
2021-03-09 21:54 ` Philippe Mathieu-Daudé
2021-03-10 17:06 ` Peter Xu
2021-03-10 19:09 ` Philippe Mathieu-Daudé
2021-03-10 19:12 ` [PATCH 1/2] hw/mips/jazz: Use generic I/O bus via get_system_io() Philippe Mathieu-Daudé
2021-03-10 19:12 ` [PATCH 2/2] NOTFORMERGE memory: Ensure AddressSpace physical base address is zero Philippe Mathieu-Daudé
2021-03-10 19:49 ` [PATCH 1/2] hw/mips/jazz: Use generic I/O bus via get_system_io() Peter Xu
2021-03-10 20:11 ` Philippe Mathieu-Daudé
2021-03-10 20:29 ` Peter Xu
2021-03-11 12:18 ` Philippe Mathieu-Daudé
2021-03-11 16:21 ` Philippe Mathieu-Daudé
2021-03-11 17:27 ` Peter Xu [this message]
2021-03-11 17:59 ` Philippe Mathieu-Daudé
2021-03-12 9:08 ` Cédric Le Goater
2021-03-11 17:27 ` Peter Xu
2021-03-11 17:41 ` Philippe Mathieu-Daudé
2021-03-11 0:48 ` Jiaxun Yang
2021-03-10 19:31 ` [PATCH 2/3] memory: Provide 'base address' argument to mtree_print_mr() Peter Xu
2021-03-10 22:00 ` Mark Cave-Ayland
2021-03-05 23:54 ` [PATCH 3/3] memory: Make memory_region_to_absolute_addr() take a const MemoryRegion Philippe Mathieu-Daudé
2021-03-11 12:19 ` Philippe Mathieu-Daudé
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=20210311172710.GH194839@xz-x1 \
--to=peterx@redhat.com \
--cc=aleksandar.rikalo@syrmia.com \
--cc=alxndr@bu.edu \
--cc=andrew@aj.id.au \
--cc=aurelien@aurel32.net \
--cc=clg@kaod.org \
--cc=edgar.iglesias@gmail.com \
--cc=f4bug@amsat.org \
--cc=hpoussin@reactos.org \
--cc=joel@jms.id.au \
--cc=laurent@vivier.eu \
--cc=mark.cave-ayland@ilande.co.uk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).