Re: [Qemu-devel] [for-2.11 PATCH 24/26] spapr: allow guest to update the XICS phandle

[David Gibson]

On Tue, Aug 01, 2017 at 01:26:15PM +0200, Greg Kurz wrote:
> On Tue, 1 Aug 2017 12:20:56 +1000
> Alexey Kardashevskiy <address@hidden> 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 <address@hidden>
> > >>>> Signed-off-by: Greg Kurz <address@hidden>  
> > >>>
> > >>> 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