[SLOF] [PATCH slof v2] fdt: Pass the resulting device tree to QEMU

[David Gibson]

On Tue, Oct 03, 2017 at 12:07:15PM +1100, Alexey Kardashevskiy wrote:
> On 03/10/17 09:48, Greg Kurz wrote:
> > On Mon,  2 Oct 2017 16:38:19 +1100
> > Alexey Kardashevskiy <aik at ozlabs.ru> 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.
> >>
> >> Signed-off-by: Alexey Kardashevskiy <aik at ozlabs.ru>
> >> ---
> >>
> >> Changes:
> >> v2:
> >> * fixed comments from review
> >> * added strings cache
> >> * changed last_compat_vers from 0x17 to 0x16 as suggested by dwg
> >>
> > 
> > It isn't 0x17 and 0x16 but 0x11 and 0x10 actually, fdt-flatten-tree
> > needs to be changed accordingly :)
> 
> Hmmm. I looked at dtc - there the latest is 0d17 so you seem to be right.
> But when I did this patch, I just looked at the beginning of
> board-qemu/slof/fdt.fs:
> 
> 
>  53 : fdt-check-header ( -- )
> 
> [...]
>  72         dup >fdth_version l@ 17 >= IF
> 
>  73             ."  struct size      : 0x" dup >fdth_struct_size l@ . cr
> 
>  74         THEN
> 
> 
> 
> Oopsie. I guess this should be 0x11 rather than 0x17, it is like that since
> the initial import.

Uh, yes.  I think you've gotten away with that because it just means
SLOF would have ignored the extra v17 field, even on v17.  That would
work, the field is technically redundant, just means you can find the
size of the structure block without having to scan right through it.
Since SLOF will need to scan right through it anyway, it probably
didn't really need it.

-- 
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/20171003/3a61cf03/attachment.sig>