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

[Mark Cave-Ayland]

On 06/09/17 14:41, Segher Boessenkool wrote:

> On Wed, Sep 06, 2017 at 02:33:45PM +0200, Greg Kurz wrote:
>> But David Gibson seems to be "really, really" opposed to this solution as
>> expressed in this thread:
>>
>> https://lists.nongnu.org/archive/html/qemu-ppc/2017-07/msg00556.html
>>
>> He's asking if we can change SLOF to not use phandles as raw pointers
>> instead... I must admit that this goes way beyond my very limited
>> knowledge on SLOF and forth... :-\
> 
> A phandle is an opaque cookie to everything but the firmware itself.
> Using pointers to some internal structure works just fine; most Open
> Firmware implementations do this.
> 
> Anything other than OF itself should *not* make up phandles.  There
> is no way to guarantee these will be unique, so it is a non-starter.
> 
> If QEMU wants to create a device node, it should ask OF to do it,
> say, via new-device.

Definitely phandles should be considered an opaque for use by the
firmware only, so I agree the approach in this patch sounds wrong.

I think I missed the first part of this thread, however can someone
explain why hotplug devices need to update the SLOF DT? All OSs I've
seen iterate the entire DT and store a local copy during early boot,
primarily because once you've taken over memory management it's almost
impossible to call OF without crashing because the OF doesn't have
complete knowledge of the kernel mappings.

Therefore if the guest OS doesn't read the DT after early boot, and it
can handle the hotplug itself then why does OF need to know? Surely it
would just pick up the new device in the updated DT generated by QEMU at
the next reset as normal?


ATB,

Mark.