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

[Alexey Kardashevskiy]

On 03/10/17 09:39, Greg Kurz wrote:
> On Tue, 3 Oct 2017 09:22:38 +1100
> Alexey Kardashevskiy <aik at ozlabs.ru> wrote:
> 
>> On 03/10/17 03:18, 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 wanted to give a try with PHB hotplug and SLOF breaks, because...  
>>
>> How does it break exactly? I agree I do not clear the stack but it did not
>> show up in any form :-/
>>
> 
> Device tree strings 0x0000000004c90000 -> 0x0000000004c90a88
> Device tree struct  0x0000000004ca0000 -> 0x0000000004cb0000
> +++Q+++ (15990) h_update_dt 1676: DT at 7e43b000 (7e43b000) 19340 bytes
>  
> 
> ( 700 ) Program Exception [ 7dc4b218 ]
> 
> 
>     R0 .. R7           R8 .. R15         R16 .. R23         R24 .. R31
> 000000007dbe2ea8   000000007e463010   0000000000000000   0000000000000006   
> 000000007e666fe0   000000007dc4b220   0000000000000000   000000007dc05500   
> 000000007dc0eb00   000000007e711048   000000007e463010   000000007dc090e8   
> 000000007dc4d000   000000007dbe8510   000000007dc092b8   0000000000000003   
> 000000007dc5f320   000000007dbe84f0   0000000000008000   000000000000f001   
> 000000007dc4b218   0000000000000000   000000000000f003   ffffffffffffffff   
> 000000007e711050   0000000000000000   000000000000f004   000000007dc0ae08   
> 0000000000000003   0000000000000000   000000000000f005   0000000000000000   
> 
>     CR / XER           LR / CTR          SRR0 / SRR1        DAR / DSISR
>         80000408   000000007dbe3534   000000007dc0ae08   0000000000000000   
> 0000000000000000   000000007dc0ae08   8000000000081000           00000000   
> 
> 
> 45 >  
> 
> ( 300 ) Data Storage Exception [ 7dc4b240 ]
> 
> 
>     R0 .. R7           R8 .. R15         R16 .. R23         R24 .. R31
> 000000007dbe0308   000000007e463010   0000000000000000   0000000000000006   
> 000000007e666fe0   4800000824000051   0000000000000000   000000007dc05500   
> 000000007dc0eb00   000000007dc4b260   000000007e463010   000000007dc090e8   
> 0000000000000064   000000007dc4eb00   000000007dc092b8   0000000000000003   
> 0000000000000000   000000007dbe84f0   0000000000008000   000000000000f001   
> 000000007dc4b240   0000000000000000   000000000000f003   ffffffffffffffff   
> 000000007dc09f30   0000000000000000   000000000000f004   000000007dbe3ba0   
> 4800000824000051   0000000000000000   000000000000f005   000000007dc099a8   
> 
>     CR / XER           LR / CTR          SRR0 / SRR1        DAR / DSISR
>         80000404   000000007dbe3490   000000007dbe42c4   4800000824000051   
> 0000000020000000   000000007dbe3ba0   8000000000001000           40000000   
> 
> I presume that this is the consequence of having 0 on top of the stack
> when calling fdt-flatten-tree-free, or am I missing something ?


It could be, I just wonder why it did not crash on my machine, it usually
crashes when I screw up with the stack in forth :-/


-- 
Alexey