qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [for-2.11 PATCH 24/26] spapr: allow guest to


From: Greg Kurz
Subject: Re: [Qemu-ppc] [Qemu-devel] [for-2.11 PATCH 24/26] spapr: allow guest to update the XICS phandle
Date: Tue, 1 Aug 2017 13:26:15 +0200

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.

Cheers,

--
Greg

Attachment: pgpi7hk41dofi.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]