qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Bin Meng <bmeng.cn@gmail.com>
Cc: thuth@redhat.com, "open list:RISC-V" <qemu-riscv@nongnu.org>,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	laurent@vivier.eu, qemu-ppc@nongnu.org, alistair.francis@wdc.com,
	david@gibson.dropbear.id.au
Subject: Re: [PATCH 1/6] hw/riscv: microchip_pfsoc: Use MachineState::ram and MachineClass::default_ram_id
Date: Wed, 20 Oct 2021 10:32:15 +0200	[thread overview]
Message-ID: <20211020103215.17288634@redhat.com> (raw)
In-Reply-To: <CAEUhbmUa1CU_7+HMEuBmAc-DqFAH8iByfDAjV_uXnof6TZQz_Q@mail.gmail.com>

On Wed, 20 Oct 2021 09:55:52 +0800
Bin Meng <bmeng.cn@gmail.com> wrote:

> Hi Igor,
> 
> On Tue, Oct 19, 2021 at 3:39 PM Igor Mammedov <imammedo@redhat.com> wrote:
> >
> > On Mon, 18 Oct 2021 23:38:24 +0800
> > Bin Meng <bmeng.cn@gmail.com> wrote:
> >  
> > > Using memory_region_init_ram(), which can't possibly handle vhost-user,
> > > and can't work as expected with '-numa node,memdev' options.
> > >
> > > Use MachineState::ram instead of manually initializing RAM memory
> > > region, as well as by providing MachineClass::default_ram_id to
> > > opt in to memdev scheme.
> > >
> > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > > ---
> > >
> > >  hw/riscv/microchip_pfsoc.c | 9 +++------
> > >  1 file changed, 3 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
> > > index e475b6d511..f10f55b488 100644
> > > --- a/hw/riscv/microchip_pfsoc.c
> > > +++ b/hw/riscv/microchip_pfsoc.c
> > > @@ -459,7 +459,6 @@ static void microchip_icicle_kit_machine_init(MachineState *machine)
> > >      const MemMapEntry *memmap = microchip_pfsoc_memmap;
> > >      MicrochipIcicleKitState *s = MICROCHIP_ICICLE_KIT_MACHINE(machine);
> > >      MemoryRegion *system_memory = get_system_memory();
> > > -    MemoryRegion *mem_low = g_new(MemoryRegion, 1);
> > >      MemoryRegion *mem_low_alias = g_new(MemoryRegion, 1);
> > >      MemoryRegion *mem_high = g_new(MemoryRegion, 1);
> > >      MemoryRegion *mem_high_alias = g_new(MemoryRegion, 1);
> > > @@ -486,16 +485,13 @@ static void microchip_icicle_kit_machine_init(MachineState *machine)
> > >      qdev_realize(DEVICE(&s->soc), NULL, &error_abort);
> > >
> > >      /* Register RAM */
> > > -    memory_region_init_ram(mem_low, NULL, "microchip.icicle.kit.ram_low",
> > > -                           memmap[MICROCHIP_PFSOC_DRAM_LO].size,
> > > -                           &error_fatal);
> > >      memory_region_init_alias(mem_low_alias, NULL,
> > >                               "microchip.icicle.kit.ram_low.alias",
> > > -                             mem_low, 0,
> > > +                             machine->ram, 0,
> > >                               memmap[MICROCHIP_PFSOC_DRAM_LO_ALIAS].size);
> > >      memory_region_add_subregion(system_memory,
> > >                                  memmap[MICROCHIP_PFSOC_DRAM_LO].base,
> > > -                                mem_low);
> > > +                                machine->ram);
> > >      memory_region_add_subregion(system_memory,
> > >                                  memmap[MICROCHIP_PFSOC_DRAM_LO_ALIAS].base,
> > >                                  mem_low_alias);  
> >
> > looking at code it seems RAM is split between low and high regions,
> > so converting only low region is wrong.
> >
> > I'd suggest something similar to 2dc9ce13d210 : taihu_405ep_init().
> > i.e. ms->ram should hold whole RAM that is split between low and high
> > using aliases.  
> 
> Thank you for your pointers. I have just sent v2.


 
> One note when looking at the taihu_405ep_init() implementation, the
> following looks incorrect to me:
> 
>     memory_region_init_alias(&ram_memories[1], NULL,
>                              "taihu_405ep.ram-1", machine->ram, ram_bases[1],
>                              ram_sizes[1]);
> 
> I think the 'offset' should be ram_sizes[0] instead of ram_bases[1],
> although their values are the same which means they are two contiguous
> regions, so it happens to work. But I might be nitpicking ...

I fail to see what's wrong there, from the way code is written
it looks like hardware has 2 memory banks with different base
address. It just happens that ram_bases[1] starts right after
ram_bases[0] but if it weren't then using ram_sizes[0]
for offset would be wrong. So current code looks fine to me.

Anyways,
CCing PPC folks to have a second look at it.

> 
> >  
> > > @@ -606,6 +602,7 @@ static void microchip_icicle_kit_machine_class_init(ObjectClass *oc, void *data)
> > >                     MICROCHIP_PFSOC_COMPUTE_CPU_COUNT;
> > >      mc->min_cpus = MICROCHIP_PFSOC_MANAGEMENT_CPU_COUNT + 1;
> > >      mc->default_cpus = mc->min_cpus;
> > > +    mc->default_ram_id = "microchip.icicle.kit.ram_low";  
> >
> > given it is not versioned machine, so we don't have to worry about
> > cross version migration here,
> > so I'd use "microchip.icicle.kit.ram" for the name here
> > and currently used "microchip.icicle.kit.ram_low" for corresponding alias  
> 
> Regards,
> Bin
> 



      reply	other threads:[~2021-10-20  8:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-18 15:38 [PATCH 1/6] hw/riscv: microchip_pfsoc: Use MachineState::ram and MachineClass::default_ram_id Bin Meng
2021-10-18 15:38 ` [PATCH 2/6] hw/riscv: opentitan: " Bin Meng
2021-10-19  7:11   ` Igor Mammedov
2021-10-19 12:57     ` Bin Meng
2021-10-18 15:38 ` [PATCH 3/6] hw/riscv: shakti_c: " Bin Meng
2021-10-19  7:12   ` Igor Mammedov
2021-10-18 15:38 ` [PATCH 4/6] hw/riscv: sifive_e: " Bin Meng
2021-10-19  7:15   ` Igor Mammedov
2021-10-18 15:38 ` [PATCH 5/6] hw/riscv: sifive_u: " Bin Meng
2021-10-19  7:16   ` Igor Mammedov
2021-10-18 15:38 ` [PATCH 6/6] hw/riscv: spike: " Bin Meng
2021-10-19  7:17   ` Igor Mammedov
2021-10-18 15:51 ` [PATCH 1/6] hw/riscv: microchip_pfsoc: " Philippe Mathieu-Daudé
2021-10-18 16:00   ` Bin Meng
2021-10-19  7:39 ` Igor Mammedov
2021-10-20  1:55   ` Bin Meng
2021-10-20  8:32     ` Igor Mammedov [this message]

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=20211020103215.17288634@redhat.com \
    --to=imammedo@redhat.com \
    --cc=alistair.francis@wdc.com \
    --cc=bmeng.cn@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=laurent@vivier.eu \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=thuth@redhat.com \
    /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).