Re: [Qemu-devel] [Qemu-ppc] [PATCH v5 1/6] ppc: spapr: Register and handle HCALL to receive updated RTAS region

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

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

On Mon, Oct 02, 2017 at 02:02:19PM +1100, Alexey Kardashevskiy wrote:
> On 29/09/17 21:52, Nikunj A Dadhania wrote:
> > David Gibson <david@gibson.dropbear.id.au> writes:
> > 
> >> On Thu, Sep 28, 2017 at 04:07:38PM +0530, Aravinda Prasad wrote:
> >>> Receive updates from SLOF about the updated rtas-base.
> >>> A separate patch for SLOF [1] (commit f9a60de3) adds
> >>> functionality to invoke a private HCALL whenever OS
> >>> issues instantiate-rtas with a new rtas-base.
> >>>
> >>> This is required as QEMU needs to know the updated rtas-base
> >>> as it allocates error reporting structure in RTAS space upon
> >>> a machine check exception.
> >>>
> >>> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120386.html
> >>>
> >>> Signed-off-by: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
> >>> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> >>
> >> Ao I acked this earlier, but I've now realized there might be some
> >> connection between this and discussions taking place elsewhere about
> >> qemu not knowing what SLOF does with the device tree.
> >>
> >> At what point will SLOF call the UPDATE_RTAS hcall?  I'm guessing at
> >> the time of instantiate-rtas, is that right?
> > 
> > The call happens from
> > arch/powerpc/kernel/prom_init.c:prom_instantiate_rtas() and after that
> > linux kernel makes two entries in the DT
> > 
> > ....
> >        if (call_prom_ret("call-method", 3, 2, &entry,
> >                           ADDR("instantiate-rtas"),
> >                           rtas_inst, base) != 0
> >             || entry == 0) {
> >                 prom_printf(" failed\n");
> >                 return;
> >         }
> >         prom_printf(" done\n");
> > 
> >         reserve_mem(base, size);
> > 
> >         val = cpu_to_be32(base);
> >         prom_setprop(rtas_node, "/rtas", "linux,rtas-base",
> >                      &val, sizeof(val));
> >         val = cpu_to_be32(entry);
> >         prom_setprop(rtas_node, "/rtas", "linux,rtas-entry",
> >                      &val, sizeof(val));
> > ....
> > 
> > Quiesce is called after this. 
> > 
> >> Does SLOF put the RTAS blob address in its internal device tree, or
> >> does it only pass it to the guest via the return parameters from
> >> instantiate-rtas?
> > 
> > Entry was made to the DT by linux kernel prom_init code, will this be
> > visible to QEMU?
> 
> With my recent SLOF FDT patch - yes:
> 
> aik@fstn1-p1:~$ grep rtas dbg.dts
> 	rtas {
> 		linux,rtas-entry = <0x2fff0000>;
> 		linux,rtas-base = <0x2fff0000>;
> [...]

Ah.. except.. isn't that relying on the kernel putting the RTAS
address into the device tree before it calls quiesce and kills SLOF?

The SLOF image is bundled in with qemu, so it's ok for us to rely on
its behaviour up to a point.  It's not really ok for us to rely on the
kernel's behaviour here, unless that behaviour is mandated by PAPR,
which this isn't.

So, I think we either need to have *SLOF* update the device tree with
that address at instantiate-rtas time, or we'll need to resurrect
Aravinda's original UPDATE_RTAS hcall.

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