On Tue, Aug 01, 2017 at 01:26:15PM +0200, Greg Kurz wrote: > On Tue, 1 Aug 2017 12:20:56 +1000 > Alexey Kardashevskiy <a...@ozlabs.ru> wrote: > > > On 31/07/17 14:58, David Gibson wrote: > > > On Fri, Jul 28, 2017 at 08:20:57AM +0200, Thomas Huth wrote: > > >> On 28.07.2017 06:02, David Gibson wrote: > > >>> On Tue, Jul 25, 2017 at 08:03:06PM +0200, Greg Kurz wrote: > > >>>> The "phandle" property of the XICS node is referenced by the > > >>>> "interrupt-map" > > >>>> property of each PHB node. This is used by the guest OS to setup IRQs > > >>>> for > > >>>> all PCI devices. > > >>>> > > >>>> QEMU uses an arbitrary value (0x1111) for this phandle, but SLOF > > >>>> converts > > >>>> this value to a SLOF specific one, which is then presented to the > > >>>> guest OS. > > >>>> > > >>>> This patches introduces the new KVMPPC_H_UPDATE_PHANDLE hcall, which > > >>>> is used > > >>>> by SLOF to communicate the patched phandle value back to QEMU. This > > >>>> value > > >>>> is then cached and preserved accross migration until machine reset. > > >>>> > > >>>> This is required to be able to support PHB hotplug. > > >>>> > > >>>> Note, that SLOF already has some code to call KVMPPC_H_RTAS_UPDATE, so > > >>>> we > > >>>> have to introduce its number even if QEMU currently doesn't implement > > >>>> it. > > >>>> > > >>>> Suggested-by: Thomas Huth <th...@redhat.com> > > >>>> Signed-off-by: Greg Kurz <gr...@kaod.org> > > >>> > > >>> Ugh. I really, really hope we can avoid this, though I don't > > >>> immediately see how. Having to have two way communication between > > >>> qemu and SLOF about the device tree contents just seems like opening > > >>> the door to endless complexities. > > >>> > > >>> This is basically a consequence of the fact that both qemu and partly > > >>> responsible for constructing the device tree for the guest, and that's > > >>> not easy to avoid. > > >>> > > >>> Hrm.. Thomas, I know it's not really the OF way, but would it be > > >>> feasible to change SLOF to use the phandles as supplied by qemu rather > > >>> than creating its own? > > >> > > >> I don't see a way to do this in an easy, clean, reasonable way. SLOF > > >> uses pointers to internal structures as phandles all over the place. You > > >> likely can't replace that so easily without rewriting half of the whole > > >> device tree related code in SLOF, I guess... > > > > > > Dang, that's what I suspected. > > > > > > Just to be clear the phandles are used directly as raw pointers? > > > There's not even some lookup macro we could change? > > > > > > > We would need to rewrite > > https://github.com/aik/SLOF/blob/master/slof/fs/node.fs > > > > Since SLOF does not seem to use phandles as pointers directly anywhere but > > in nofe.fs, this should be doable. Easier said than done though. > > > > Yikes... If we go that way, I'll definitely need some assistance and time. > > Cc'ing Nikunj for some extra advices.
Yeah, I hope we could get a feasibility idea from someone who knows Forth - Thomas or Nikunj, maybe. I'd be thinking of replacing the direct pointer dereferences for phandles with a simple lookup table of phandle to pointer, populated as we unflatten the tree. -- 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
signature.asc
Description: PGP signature