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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3407 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]