From: David Gibson <david@gibson.dropbear.id.au>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: linuxppc-dev@lists.ozlabs.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>, Greg Kurz <groug@kaod.org>,
Balbir Singh <bsingharora@gmail.com>,
Thomas Huth <thuth@redhat.com>,
Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>,
slof@lists.ozlabs.org
Subject: Re: [PATCH kernel] RFC: prom_init: Fetch flatten device tree from the system firmware
Date: Mon, 16 Oct 2017 17:46:33 +1100 [thread overview]
Message-ID: <20171016064633.GE2776@umbus.fritz.box> (raw)
In-Reply-To: <00ec0e99-45dd-dbe0-d75f-4413253e8093@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 4162 bytes --]
On Mon, Oct 16, 2017 at 05:22:55PM +1100, Alexey Kardashevskiy wrote:
> On 16/10/17 17:11, David Gibson wrote:
> > On Mon, Oct 16, 2017 at 04:49:17PM +1100, Alexey Kardashevskiy wrote:
> >> At the moment, on 256CPU + 256 PCI devices guest, it takes the guest
> >> about 8.5sec to read the entire device tree. Some explanation can be
> >> found here: https://patchwork.ozlabs.org/patch/826124/ but mostly it is
> >> because the kernel traverses the tree twice and it calls "getprop" for
> >> each properly which is really SLOF as it searches from the linked list
> >> beginning every time.
> >>
> >> Since SLOF has just learned to build FDT and this takes less than 0.5sec
> >> for such a big guest, this makes use of the proposed client interface
> >> method - "fdt-fetch".
> >>
> >> If "fdt-fetch" is not available, the old method is used.
> >>
> >> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >
> > I like the concept, few details though..
> >
> >> ---
> >> arch/powerpc/kernel/prom_init.c | 26 ++++++++++++++++++++++++++
> >> 1 file changed, 26 insertions(+)
> >>
> >> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> >> index 02190e90c7ae..daa50a153737 100644
> >> --- a/arch/powerpc/kernel/prom_init.c
> >> +++ b/arch/powerpc/kernel/prom_init.c
> >> @@ -2498,6 +2498,31 @@ static void __init flatten_device_tree(void)
> >> prom_panic("Can't allocate initial device-tree chunk\n");
> >> mem_end = mem_start + room;
> >>
> >> + if (!call_prom_ret("fdt-fetch", 2, 1, NULL, mem_start,
> >> + room - sizeof(mem_reserve_map))) {
> >> + u32 size;
> >> +
> >> + hdr = (void *) mem_start;
> >> +
> >> + /* Fixup the boot cpuid */
> >> + hdr->boot_cpuid_phys = cpu_to_be32(prom.cpu);
> >
> > If SLOF is generating a tree it really should get this header field
> > right as well.
>
>
> Ah, I did not realize it is just a phandle from /chosen/cpu. Will
> fix.
It's not a phandle. It's just the "address" (i.e. reg value) of the
boot cpu.
> >> + /* Append the reserved map to the end of the blob */
> >> + hdr->off_mem_rsvmap = hdr->totalsize;
> >> + size = be32_to_cpu(hdr->totalsize);
> >> + rsvmap = (void *) hdr + size;
> >> + hdr->totalsize = cpu_to_be32(size + sizeof(mem_reserve_map));
> >> + memcpy(rsvmap, mem_reserve_map, sizeof(mem_reserve_map));
> >
> > .. and the reserve map for that matter. I don't really understand
> > what you're doing here.
>
> ? Get the blob, increase the FDT size by sizeof(mem_reserve_map), fix up
> totalsize and off_mem_rsvmap, copy mem_reserve_map to the end of the blob
> (the actual order is slightly different, may be a bit confusing).
Right.. but where is mem_reserve_map coming from, if it hasn't come
from an FDT?
> Asking SLOF to reserve the space seems to be unnecessary complication of
> the interface - SLOF does not provide any reserved memory records.
Ah.. right, the reservations are coming from the pre-prom kernel, not
from the firmware itself. Yeah, that makes sense. Ok, this makes
sense then...
> > Note also that the reserve map is required to
> > be 8-byte aligned, which totalsize might not be.
>
> Ah, good point.
..at least with that fixed and maybe some comments to make what's
gonig on clearer.
>
>
> >
> >> + /* Store the DT address */
> >> + dt_header_start = mem_start;
> >> +
> >> +#ifdef DEBUG_PROM
> >> + prom_printf("Fetched DTB: %d bytes to @%x\n", size, mem_start);
> >> +#endif
> >> + goto print_exit;
> >> + }
> >> +
> >> /* Get root of tree */
> >> root = call_prom("peer", 1, 1, (phandle)0);
> >> if (root == (phandle)0)
> >> @@ -2548,6 +2573,7 @@ static void __init flatten_device_tree(void)
> >> /* Copy the reserve map in */
> >> memcpy(rsvmap, mem_reserve_map, sizeof(mem_reserve_map));
> >>
> >> +print_exit:
> >> #ifdef DEBUG_PROM
> >> {
> >> int i;
> >
>
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-10-16 6:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-16 5:49 [PATCH kernel] RFC: prom_init: Fetch flatten device tree from the system firmware Alexey Kardashevskiy
2017-10-16 6:11 ` David Gibson
2017-10-16 6:22 ` Alexey Kardashevskiy
2017-10-16 6:46 ` David Gibson [this message]
2017-10-16 7:07 ` Alexey Kardashevskiy
2017-10-16 9:05 ` David Gibson
2017-10-16 10:20 ` Segher Boessenkool
2017-10-16 11:08 ` Alexey Kardashevskiy
2017-10-16 11:59 ` Michael Ellerman
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=20171016064633.GE2776@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=aik@ozlabs.ru \
--cc=benh@kernel.crashing.org \
--cc=bsingharora@gmail.com \
--cc=groug@kaod.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=nikunj@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=slof@lists.ozlabs.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).