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

[David Gibson]

On Thu, Sep 07, 2017 at 03:13:16AM -0500, Segher Boessenkool wrote:
> 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?

Because the firmware needs to know about non-PCI devices too.  That
includes both things like PAPR virtual IO devices, and also the PCI
host bridges themselves.  Firmware can't probe for BARs until it can
access config space, and it can't do that until it has a handle on the
host bridges.

Remember that there is no real hardware we're emulating here that OF
can use the same probes for.  This is a purely paravirtual platform
which assumes the firmware "just knows" what's going on.  "Seeding"
the OF tree with an FDT was our chosen way to get that information
into guest firmware; it's pretty much the simplest option.

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

In most cases it is; that's why we haven't needed this yet.  The
problem case is hotplugging of an entire PCI host bridge.  That needs
an interrupt map to remap the PCI interrupt descriptors to XICs
interrupts.

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

Hmm.  I don't really see how it can be impossible.  There has to be
some sort of "lookup phandle" operation - they don't *have* to be
pointers (and couldn't be for, e.g. a trye 64-bit OF implementation).
And if there's that we can have a lookup table to find the internal
pointers.

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

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/slof/attachments/20170907/947bb2a4/attachment.sig>