[SLOF] [PATCH v4] board-qemu: add private hcall to inform host on "phandle" update

[Alexey Kardashevskiy]

On 25/07/17 16:30, Alexey Kardashevskiy wrote:
> On 25/07/17 16:14, Thomas Huth wrote:
>> On 25.07.2017 07:37, Alexey Kardashevskiy wrote:
>>> Thomas,
>>>
>>> What is this business with phandle replacements all about? I looked at the
>>> history which says "SLOF has a different concept of phandles" but it does
>>> not say what would break if SLOF kept using phandles from QEMU.
>>>
>>> I applied the chunk below and could not see any difference in how SLOF or a
>>> guest kernel behave (slof can boot from virtio-net, guest can use mellanox
>>> iov vfio-pci device):
>>>
>>> diff --git a/board-qemu/slof/fdt.fs b/board-qemu/slof/fdt.fs
>>> index a24e344..54a4bf8 100644
>>> --- a/board-qemu/slof/fdt.fs
>>> +++ b/board-qemu/slof/fdt.fs
>>> @@ -449,4 +449,4 @@ r> drop
>>>      fdt-cas-fix?
>>>  ;
>>>
>>> -s" /" find-node fdt-fix-phandles
>>> +\ s" /" find-node fdt-fix-phandles
>>>
>>> What am I missing here?
>>
>> QEMU uses the FDT concept of phandles, i.e. it puts a "phandle" and
>> "linux,phandle" property into the corresponding device tree nodes. SLOF
>> uses the concept of Open Firmware phandles, i.e. the normal code does
>> not know about these properties and uses its own way of managing
>> phandles - which are pointer to data structures here. So if you leave
>> the properties in the device tree, you present Linux with a device tree
>> where a node suddenly has two different phandles - the FDT phandle from
>> QEMU and the Open Firmware phandle from SLOF.
> 
> SLOF does not create phandle properties (or does it?), whatever QEMU
> provides stays there, linux creates linux,phandle properties but if it is
> already in the tree, it remains unchanged.
> 
> May be there is some use of these phandles like RTAS which I am not aware
> of? Or the guest kernel assumes something about the nature of phandles
> (unlikely)?


Ah, figured it out, it is all my ignorance :(

The guest's arch/powerpc/kernel/prom_init.c traverses the tree using
call_prom()  and this is where these SLOF's nodes come up so yes, we are
better off staying in sync with that.

> 
> 
>> Not sure how Linux reacts to such a device tree ...
>> it could work by accident, but it could also
>> confuse the kernel completely. It's certainly wrong to do this, so I
>> think Greg's patch is the right way to go here, even if it looks a
>> little bit more complicated at a first glance.


-- 
Alexey