[SLOF] [PATCH slof v3 5/5] fdt: Pass the resulting device tree to QEMU
aik at ozlabs.ru
Tue Oct 3 20:09:28 AEDT 2017
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
> 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
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>
>> * 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
>> * 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 839 bytes
Desc: OpenPGP digital signature
More information about the SLOF