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

[Alexey Kardashevskiy]

On 03/10/17 17:28, David Gibson wrote:
> On Tue, Oct 03, 2017 at 04:15:23PM +1100, Alexey Kardashevskiy wrote:
>> This creates flatten device tree and passes it to QEMU via a custom
>> hypercall right before jumping to RTAS.
> 
> Uh.. "right before jumping to RTAS" isn't very clear to me.  It's
> called at quiesce time, right, which we anticipate is the last thing
> SLOF will do before being wiped away by the OS.  That's not really
> connected to RTAS AFAICT.
> 

I did not think much on this paragraph, sorry :)


>> 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.
> 
> Hrm.  360/16 * 38ms = 855ms < 1s.

My simple case does not do PCI, with a PCI bridge and a E1000 it is 45ms.
But I see your point. It is j

>  Which suggests we have something
> that's slower than O(n) here, which is concerning.  256 cpus and 256
> devices is largish, but it's not a ludicrous size.

With 255 PCI devices, there are quite many bridges with property names
which I do not preload, that could explain.


>> 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.
> 
> Blech, that's a prety ugly set of tradeoffs.  When I suggested this
> approach I hadn't thought it would take so long to flatten the tree in
> Forth.

Fetching the tree to the guest kernel takes close to 10 seconds though,
using the client interface. Just to compare.

I can look at what Segher suggested when mentioned a word list, not sure
what this is and how it can help but worth to try I guess.


>>
>> 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
> 
> The reason for this error is it's not to do with the "node name" as
> given after the FDT_BEGIN_TAG, but with the "name" property.  That's
> not required in FDT, but if supplied should match that node name
> exactly.  IIRC, however, for human readability runtime OF treats
> 'name' of the root node as being '/'.
> 
> Arguably that is a bug in dtc - '/' as the name property in the root
> is probably acceptable.  On the other hand, you should probably just
> omit the 'name' properties when you flatten the tree.

Ok, will do this.



-- 
Alexey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 839 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/slof/attachments/20171003/2b3a0f08/attachment-0001.sig>