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

[Segher Boessenkool]

Hi!

So I have some questions...  I don't understand why all this is so hard:

On Thu, Sep 07, 2017 at 04:38:00PM +1000, David Gibson wrote:
> No, it would be a complete PITA.  We'd have to have a way of running
> the guest (running SLOF) concurrent with the qemu machine reset code,
> communicating OF commands in, and responses back.  As it is now, we
> just drop the FDT into guest memory before SLOF executes its first
> instruction.

Why do you pass around FDT pieces?  Why not simply make (say) a PCI BAR
visible?

> The problem comes when we need to do hotplug, and qemu needs to inject
> DT fragments long after SLOF is dead.  So far it works, because the
> only things about the existing output-from-SLOF tree we rely on would
> be completely perverse for SLOF to gratuitously change from the
> input-to-SLOF DT.  To allow PHB hotplug, though, we need the master
> XICS phandle, and SLOF *does* change all the phandles, so we don't
> know it.  Hence this proposal.

Why is there an interrupt map in the hotplugged piece?  Why not in its
parent instead?

> I'm not sure exactly what you mean by this.  Converting SLOF to use
> qemu supplied phandles everywhere would be possible, I think, but very
> awkward and ugly.

It isn't completely possible either.  The root node is special, you
will have problems with some support packages, ihandles and interposing
will be a royal pain if you can make it work at all.

> It doesn't.  The problem is that it needs to *know* a phandle that
> SLOF made up in order to make a compatible hotplug fragment.  At
> present it has no way to do that - qemu never sees the
> output-from-SLOF DT.

So, see the above two questions.


Segher