qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alexander Graf <agraf@suse.de>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
	"list@suse.de:PReP" <qemu-ppc@nongnu.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH] spapr: make sure RMA is in first mode of first memory node
Date: Mon, 04 Nov 2013 21:55:38 +1100	[thread overview]
Message-ID: <1383562538.4776.52.camel@pasglop> (raw)
In-Reply-To: <00DBC3F8-D221-4E59-B0D0-38E1A4C015CC@suse.de>

On Mon, 2013-11-04 at 11:44 +0100, Alexander Graf wrote:
> On 01.11.2013, at 11:21, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> 
> > SLOF gets really confused if RTAS/device-tree and everything else
> > what SLOF can use is not in the very first block of the very first
> > memory node.
> > 
> > This makes sure that the RMA area is where SLOF expects it to be.
> > 
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
> > Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> > ---
> > hw/ppc/spapr.c | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index 09dc635..09a5d94 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -1113,7 +1113,7 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args)
> >     int i;
> >     MemoryRegion *sysmem = get_system_memory();
> >     MemoryRegion *ram = g_new(MemoryRegion, 1);
> > -    hwaddr rma_alloc_size;
> > +    hwaddr rma_alloc_size, node0_size;
> >     uint32_t initrd_base = 0;
> >     long kernel_size = 0, initrd_size = 0;
> >     long load_limit, rtas_limit, fw_size;
> > @@ -1154,6 +1154,12 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args)
> >             spapr->rma_size = MIN(spapr->rma_size, 0x10000000);
> >         }
> >     }
> > +    /*
> > +     * SLOF gets confused if RMA resides not in the first block
> > +     * of the first memory node so let's fix it.
> > +     */
> > +    node0_size = (nb_numa_nodes > 1) ? node_mem[0] : ram_size;
> > +    spapr->rma_size = MIN(spapr->rma_size, node0_size);
> 
> So if I create a NUMA node of 4MB that will be my RMA? That sounds pretty broken, especially on 970.
> 
> Why does SLOF have any issues with NUMA memory nodes? It can just ignore them, no?

Because the only way SLOF knows about the RMA is by using the first
"reg" entry of the first memory node and that's *all* SLOF knows about.

If we start putting things like the DT, SLOF itself, etc... outside of
that region, it will crash.

So we "constrain" things to the rma that way.

Creating 4M nodes makes no sense anyway

Cheers,
Ben.

  reply	other threads:[~2013-11-04 10:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-01 10:21 [Qemu-devel] [PATCH] spapr: make sure RMA is in first mode of first memory node Alexey Kardashevskiy
2013-11-04 10:44 ` Alexander Graf
2013-11-04 10:55   ` Benjamin Herrenschmidt [this message]
2013-11-04 11:28     ` Alexander Graf
2013-11-04 11:50       ` Thomas Huth
2013-11-04 13:11         ` Alexey Kardashevskiy
2013-11-04 13:19           ` Peter Maydell
2013-11-04 13:35             ` Alexey Kardashevskiy
2013-11-04 22:29           ` Benjamin Herrenschmidt

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=1383562538.4776.52.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=nikunj@linux.vnet.ibm.com \
    --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).