[SLOF] [PATCH slof v2] fdt: Pass the resulting device tree to QEMU
groug at kaod.org
Tue Oct 3 16:58:13 AEDT 2017
On Tue, 3 Oct 2017 12:07:15 +1100
Alexey Kardashevskiy <aik at ozlabs.ru> 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
> 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.
I saw that too and yes, we're in hex mode so this should be 11.
More information about the SLOF