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

[Greg Kurz]

On Mon, 2 Oct 2017 19:26:41 +1100
Alexey Kardashevskiy <aik at ozlabs.ru> wrote:

> On 02/10/17 18:47, 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
> >>
> >> ---
> >>
> >> 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 |   1 +
> >>  board-qemu/slof/fdt.fs    | 297 +++++++++++++++++++++++++++++++++++++++++++++-
> >>  board-qemu/slof/rtas.fs   |   4 +
> >>  lib/libhvcall/hvcall.code |   5 +
> >>  lib/libhvcall/hvcall.in   |   1 +
> >>  5 files changed, 307 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/lib/libhvcall/libhvcall.h b/lib/libhvcall/libhvcall.h
> >> index 5776a2b..1c2d31b 100644
> >> --- a/lib/libhvcall/libhvcall.h
> >> +++ b/lib/libhvcall/libhvcall.h
> >> @@ -26,6 +26,7 @@
> >>  #define KVMPPC_H_CAS            (KVMPPC_HCALL_BASE + 0x2)
> >>  #define KVMPPC_H_RTAS_UPDATE    (KVMPPC_HCALL_BASE + 0x3)
> >>  #define KVMPPC_H_UPDATE_PHANDLE (KVMPPC_HCALL_BASE + 0x4)  
> > 
> > Since KVMPPC_H_UPDATE_PHANDLE hasn't any user obviously, and is
> > supposed to be obsoleted by this patch, maybe you can revert it
> > in the first place, no ?  
> 
> Sure, when/if this one is ready to go to upstream and QEMU at the time
> won't have H_UPDATE_PHANDLE pulled :)
> 

I hardly believe this may happen :)