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

[Greg Kurz]

On Wed, 6 Sep 2017 08:41:21 -0500
Segher Boessenkool <address@hidden> 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.
> 
> 
> Segher

Thanks for the quick answer!

Hmm... QEMU creates an FDT and writes it into the guest memory to pass
it to SLOF. QEMU uses arbitrary and unique numbers when a phandle is
needed (we just need one actually for the interrupt controller which
is referenced by each PHB). SLOF then fixes all the QEMU-generated
phandles to "opaque cookies" (see commit 82954d4c1088)... the problem
is that if we want to hotplug another PHB later on, SLOF isn't involved
anymore and QEMU doesn't know about the "opaque cookie" to be put in
the node for this PHB... I hope I'm clear enough.

This being said, you partly answer the question when you say:

"A phandle is an opaque cookie to everything but the firmware itself."

and

"Anything other than OF itself should *not* make up phandles."

Even if QEMU takes care of only forging unique phandles, it already
does some arm-twisting with the OF specification... but would it be
acceptable for SLOF to have a translation table when using phandles
generated by QEMU ?

Cheers,

--
Greg

pgpTJn3ZjyUnJ.pgp
Description: OpenPGP digital signature