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

Segher Boessenkool segher at kernel.crashing.org
Thu Sep 7 01:05:41 AEST 2017


On Wed, Sep 06, 2017 at 04:40:58PM +0200, Greg Kurz wrote:
> > 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.

> Hmm... QEMU creates an FDT and writes it into the guest memory to pass
> it to SLOF.

It probably should skip that FDT intermediate step, just create all
nodes it wants directly?  Sounds a lot simpler, and all current phandle
problems will disappear too.

> 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 cannot.  It cannot know about all phandles the firmware uses.  It
can guess, sure, but that is very fragile.

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

Then you need to translate from "qhandle" to phandle every time anything
changes, keep both up to date.  Why not just have actual phandles?
Those stay up to date always (namely, they never change).

Why does QEMU think it is a good idea to make up phandles out of thin
air?  Or, why does it do it if it is not a good idea?


Segher


More information about the SLOF mailing list