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

[Alexey Kardashevskiy]

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)?


> 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