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

[Alexey Kardashevskiy]

On 05/10/17 14:26, Alexey Kardashevskiy wrote:
> On 05/10/17 03:40, Segher Boessenkool wrote:
>> On Tue, Oct 03, 2017 at 11:13:51PM +1100, Alexey Kardashevskiy wrote:
>>>> +: fdt-properties ( phandle -- )
>>>> +    dup encode-int s" phandle" fdt-prop
>>>> +    >r
>>>> +    s" "
>>>> +    BEGIN
>>>> +        r@ next-property
>>>> +    WHILE
>>>> +        2dup
>>>> +        2dup r@ get-property
>>>> +        not IF
>>>> +            2swap fdt-prop
>>>> +        THEN
>>>> +    REPEAT
>>>> +    r>
>>>> +    drop
>>>> +;
>>>
>>>
>>> Doing as below still works but brings the time for the huge guest (256
>>> CPUs, 256 E1000) down to 366ms as it does not search for properties every
>>> time but just iterates through them, I picked this from ".properties". So
>>> we are back in business :) But I'd really love someone to explain me how
>>> that works as I am unable to parse this kind of internals myself... Segher,
>>> please.
>>
>> I'll try.
>>
>> : link>name  cell+ ;
>> : name>string  char+ count ;
>>
>> A wordlist is a linked list, offset 0 of each record is a pointer to
>> the next.  At offset 1 cell is the per-name data: a flags byte, a byte
>> that is the number of chars in the name, and the actual chars.
>>
>> Well.  The wordlists are themselves a linked list; offset 0 holds the
>> address of the next wordlist, and offset 1 cell holds the address of
>> the first name record.  Like:
>>
>> STRUCT
>>   cell FIELD wid>next
>>   cell FIELD wid>names \ the head of the list of name records
>> END-STRUCT
>>
>> STRUCT
>>   cell FIELD name>next
>>   char FIELD name>flags
>>   char FIELD name>count
>>   0    FIELD name>chars
>> END-STRUCT
> 
> 
> These do not exist in the existing SLOF code, you just typed them here, right?
> 
> I want to put these into slof/fs/node.fs right after the node struct
> definition with some comments about what points to what.
> 
> 
>>
>>
>> The default (find) implementation (from engine.in):
>>
>> : ((find))  ( str len head -- 0 | link )
>>    BEGIN dup WHILE
>>       >r 2dup r@ link>name name>string string=ci IF \ if found the name:
>>          2drop r> EXIT THEN \ return a pointer to this name record
>>       r> @ \ follow the linked list
>>    REPEAT
>>    3drop false ; \ nope, not found
>>
>>
>>> : fdt-properties ( phandle -- )
>>>     dup encode-int s" phandle" fdt-prop
>>>
>>>     node>properties @ cell+ @
>>
>> "properties" in a node struct is a wordlist, which is just a pointer
>> to the first name record in that wordlist.
> 
> 			( phandle )
> node>properties @	( properties-wordlist )
> cell+ @			( properties-names-next )
> 
> And properties-names-next points to the first 'name>next' thingy. Ok.
> 
>>
>>>     BEGIN
>>>         dup
>>>     WHILE
>>>         dup
>>>
>>>         link>
>>
>> : link>  link>name name> ;
> 
> Ahhh. I was searching for 'LINK_X3E' but it is:
> col(LINK> LINK>NAME NAME>)
> 
> Ok. Another confusion was that 'NAME' here does not point to a string but
> to 'name>flags'. Ok.
> 
> btw what does 'lfa' stand for in stack comments?
> 
> 
> So, after 'link>', the stack is:
> 			( properties-names-next end-of-name )
> 
> 
> And after that end-of-name there is/are what? One 'xt' there returns
> data+len, where does that token come from? I assume next one is 'xt' which
> prints from 'ls', right? All I am getting it all wrong and there is just
> one xt?
> 
> 
>> where name> moves to after the name (cell-aligned):
>>
>> : name>  char+ dup c@ 1+ chars+ aligned ;
>> (skip the flags byte, get the char count byte, skip that many bytes
>> (and the count byte itself), align).
>>
>>>         dup >name name>string 2>r
>>>         execute
>>>         2r>
>>>         fdt-prop
>>
>>> name tries to find the name, given an xt.  You do not need it here.
> 
> 
> Well, with this new knowledge - sounds like the name is right there between
>  properties-names-next and what 'link>' returns so I do not need extra work
> to extract it.


btw 336ms now (was 351ms), nice. See "[PATCH slof v4 2/3] fdt: Pass the
resulting device tree to QEMU" commit log for all numbers.



-- 
Alexey