qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
To: "Cédric Le Goater" <clg@kaod.org>, "Peter Xu" <peterx@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Andrew Jeffery" <andrew@aj.id.au>,
	qemu-devel@nongnu.org, qemu-arm@nongnu.org,
	"Hervé Poussineau" <hpoussin@reactos.org>,
	"Joel Stanley" <joel@jms.id.au>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	qemu-ppc@nongnu.org, "David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v2 01/11] hw/arm/aspeed: Do not directly map ram container onto main address bus
Date: Wed, 21 Apr 2021 15:02:35 +0200	[thread overview]
Message-ID: <c91b3f57-cc2c-7575-3447-715e329a4a42@amsat.org> (raw)
In-Reply-To: <1c21cbf3-c80b-4e65-485e-334ae84cefe0@kaod.org>

On 4/21/21 7:53 AM, Cédric Le Goater wrote:
> On 4/20/21 8:28 PM, Peter Xu wrote:
>> On Sat, Apr 17, 2021 at 12:30:18PM +0200, Philippe Mathieu-Daudé wrote:
>>> The RAM container is exposed as an AddressSpace.
>>
>> I didn't see where did ram_container got exposed as an address space.

I guess I used the wrong base to git-publish and skipped the first patch =)

>> I see it's added as one subregion of get_system_memory(), which looks okay? 
> my version of this patch took a simpler approach. See below.
> 
> Thanks,
> 
> C.
> 
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -327,7 +327,7 @@ static void aspeed_machine_init(MachineState *machine)
>      object_property_set_int(OBJECT(&bmc->soc), "num-cs", amc->num_cs,
>                              &error_abort);
>      object_property_set_link(OBJECT(&bmc->soc), "dram",
> -                             OBJECT(&bmc->ram_container), &error_abort);
> +                             OBJECT(machine->ram), &error_abort);

This will work as long as no board maps the main memory elsewhere than
0x0. Using the alias make it more robust (and also is good API example
for the usual "use API via copy/pasting" style when adding new board)
IMHO.

>      if (machine->kernel_filename) {
>          /*
>           * When booting with a -kernel command line there is no u-boot
> 
> 


  reply	other threads:[~2021-04-21 13:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-17 10:30 [PATCH v2 00/11] memory: Forbid mapping AddressSpace root MemoryRegion Philippe Mathieu-Daudé
2021-04-17 10:30 ` [PATCH v2 01/11] hw/arm/aspeed: Do not directly map ram container onto main address bus Philippe Mathieu-Daudé
2021-04-20 18:28   ` Peter Xu
2021-04-21  5:53     ` Cédric Le Goater
2021-04-21 13:02       ` Philippe Mathieu-Daudé [this message]
2021-04-17 10:30 ` [PATCH v2 02/11] hw/aspeed/smc: Use the RAM memory region for DMAs Philippe Mathieu-Daudé
2021-04-17 10:30 ` [PATCH v2 03/11] hw/arm/aspeed: Do not sysbus-map mmio flash region directly, use alias Philippe Mathieu-Daudé
2021-04-17 10:30 ` [PATCH v2 04/11] hw/pci-host: Rename Raven ASIC PCI bridge as raven.c Philippe Mathieu-Daudé
2021-04-19  0:46   ` David Gibson
2021-04-17 10:30 ` [PATCH v2 05/11] hw/pci-host/raven: Add PCI_IO_BASE_ADDR definition Philippe Mathieu-Daudé
2021-04-19  0:47   ` David Gibson
2021-04-17 10:30 ` [PATCH v2 06/11] hw/pci-host/raven: Assert PCI I/O AddressSpace is based at 0x80000000 Philippe Mathieu-Daudé
2021-04-19  1:00   ` David Gibson
2021-04-17 10:30 ` [PATCH v2 07/11] hw/pci-host/raven: Use MR alias for AS root, not sysbus mapped MR Philippe Mathieu-Daudé
2021-04-17 10:30 ` [RFC PATCH v2 08/11] hw/pci-host/raven: Remove pointless alias mapping onto system bus Philippe Mathieu-Daudé
2021-04-17 10:30 ` [PATCH v2 09/11] hw/pci-host/prep: Do not directly map bus-master region onto main bus Philippe Mathieu-Daudé
2021-04-17 10:30 ` [PATCH v2 10/11] memory: Make sure root MR won't be added as subregion Philippe Mathieu-Daudé
2021-04-17 10:30 ` [PATCH v2 11/11] hw/pci-host/raven: Remove temporary assertion 'root MR is zero-based' Philippe Mathieu-Daudé
2021-04-19  7:17 ` [PATCH v2 00/11] memory: Forbid mapping AddressSpace root MemoryRegion Cédric Le Goater
2021-04-19  9:48   ` Philippe Mathieu-Daudé
2021-04-20 19:07 ` Peter Xu

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=c91b3f57-cc2c-7575-3447-715e329a4a42@amsat.org \
    --to=f4bug@amsat.org \
    --cc=andrew@aj.id.au \
    --cc=clg@kaod.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=hpoussin@reactos.org \
    --cc=joel@jms.id.au \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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).