[SLOF] [PATCH slof v3 5/5] fdt: Pass the resulting device tree to QEMU

David Gibson david at gibson.dropbear.id.au
Wed Oct 4 12:02:38 AEDT 2017


On Tue, Oct 03, 2017 at 11:13:51PM +1100, Alexey Kardashevskiy wrote:
> On 03/10/17 16:15, Alexey Kardashevskiy wrote:
> > This creates flatten device tree and passes it to QEMU via a custom
> > hypercall right before jumping to RTAS.
> > 
> > On a machine with 256 CPUs and 256 virtual Intel E1000 devices the blob
> > is 360KB (356KB structs and 20KB of strings), building such a tree takes
> > ~2s on a POWER8 box. A simple tree with 1 CPU and a couple of devices
> > takes 38ms and creates 16KB blob.
> > 
> > This preloads strings with 40 property names from CPU and PCI device nodes
> > and the strings lookup only searches within these. Without string reusing
> > at all, the strings blob is 200KB and rendering time is 1.7sec; with
> > unlimited reusing, the strings blob is 4KB and rendering time is 2.8sec.
> > 
> > While we are here, fix the version handling in fdt-init. It only matters
> > a little for the fdt-debug==1 case though.
> > 
> > Signed-off-by: Alexey Kardashevskiy <aik at ozlabs.ru>
> > ---
> > 
> > Changes:
> > v3:
> > * fixed stack handling after hcall returned
> > * fixed format versions in both rendering and parsing paths
> > * rebased on top of removed unused hvcalls
> > * renamed used variables to have fdtfl- prefixes as there are already
> > some for parsing the initial dt
> > 
> > v2:
> > * fixed comments from review
> > * added strings cache
> > * changed last_compat_vers from 0x17 to 0x16 as suggested by dwg
> > 
> > ---
> > 
> > I tested the blob by storing it from QEMU to a file and decompiling it;
> > this produces error which I do not really
> > understand as the name of the root is an empty string (literaly:
> > 00 00 00 01  00 00 00 00) and yet this error:
> > 
> > aik at fstn1-p1:~$ dtc -f -I dtb -O dts -o dbg.dts dbg.dtb
> > ERROR (name_properties): "name" property in / is incorrect ("/" instead of base node name)
> > Warning: Input tree has errors, output forced
> > ---
> >  lib/libhvcall/libhvcall.h |   3 +-
> >  board-qemu/slof/fdt.fs    | 284 +++++++++++++++++++++++++++++++++++++++++++++-
> >  board-qemu/slof/rtas.fs   |   7 ++
> >  lib/libhvcall/hvcall.code |   5 +
> >  lib/libhvcall/hvcall.in   |   1 +
> >  5 files changed, 297 insertions(+), 3 deletions(-)
> > 
> 
> [...]
> 
> > diff --git a/board-qemu/slof/fdt.fs b/board-qemu/slof/fdt.fs
> > index 851645e..548cc25 100644
> > --- a/board-qemu/slof/fdt.fs
> > +++ b/board-qemu/slof/fdt.fs
> > @@ -27,7 +27,7 @@ struct
> 
> [...]
> 
> > +: fdt-properties ( phandle -- )
> > +    dup encode-int s" phandle" fdt-prop
> > +    >r
> > +    s" "
> > +    BEGIN
> > +        r@ next-property
> > +    WHILE
> > +        2dup
> > +        2dup r@ get-property
> > +        not IF
> > +            2swap fdt-prop
> > +        THEN
> > +    REPEAT
> > +    r>
> > +    drop
> > +;
> 
> 
> Doing as below still works but brings the time for the huge guest (256
> CPUs, 256 E1000) down to 366ms as it does not search for properties every

Ah, much better.  That's a cost I can live with.

> time but just iterates through them, I picked this from ".properties". So
> we are back in business :) But I'd really love someone to explain me how
> that works as I am unable to parse this kind of internals myself... Segher,
> please.
> 
> 
> : fdt-properties ( phandle -- )
>     dup encode-int s" phandle" fdt-prop
> 
>     node>properties @ cell+ @
>     BEGIN
>         dup
>     WHILE
>         dup
> 
>         link>
>         dup >name name>string 2>r
>         execute
>         2r>
>         fdt-prop
> 
>         @
>     REPEAT
> 
>     drop
> ;
> 
> 

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/slof/attachments/20171004/26ffc063/attachment.sig>


More information about the SLOF mailing list