[SLOF] [PATCH v4] board-qemu: add private hcall to inform host on "phandle" update
Segher Boessenkool
segher at kernel.crashing.org
Thu Sep 7 18:13:16 AEST 2017
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
More information about the SLOF
mailing list