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

[Thomas Huth]

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. 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.

 Thomas