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

[Alexey Kardashevskiy]

On 07/09/17 04:42, Mark Cave-Ayland wrote:
> 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? 

They do not.

When hotplug happens, QEMU provides a DT blob to the guest for a new PHB
which includes "interrupt-map" which tells how PHB interrupts are mapped to
a global interrupt controller (XICS) which is identified by that phandle.
So this blob has to have a valid XICS phandle - QEMU could get it somehow
from SLOF but this hypercall is new. QEMU makes it up instead as we needed
to construct the interrupt-map of the default PHB and it requires the XICS
phandle which is not known at the time as SLOF has not started yet and has
not generated phandles.

We could move that interrupt-map creating code ([1]) to SLOF, get rid of
the phandle fixing hack ([2]) but this won't help with hotplugged PHBs - we
will still have to have the interrupt-map code in QEMU's PHB hotplug path +
hcall from SLOF to update the XICS phandle in QEMU, propably this is the
way to go.

[1]
https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ppc/spapr_pci.c;h=d84abf1070a0ae58ef13162d00c0d80e147f1b19;hb=HEAD#l2166
[2]
https://git.qemu.org/?p=SLOF.git;a=blob;f=board-qemu/slof/fdt.fs;h=a24e3449e7c1fc61d1894d600afc95cfc6fe6518;hb=HEAD#l353


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


-- 
Alexey