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

[David Gibson]

On Wed, Oct 04, 2017 at 02:32:11PM +1100, Alexey Kardashevskiy wrote:
> On 03/10/17 20:12, Alexey Kardashevskiy wrote:
> > On 03/10/17 17:07, David Gibson wrote:
> >> 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 <address@hidden> 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 <address@hidden>
> >>>>>> Reviewed-by: David Gibson <address@hidden>
> >>>>>
> >>>>> 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:
> >>>
> >>> address@hidden:~$ 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.
> > 
> > Fair point.
> > 
> >> So, I think we either need to have *SLOF* update the device tree with
> >> that address at instantiate-rtas time,
> > 
> > I can do that, in a separate patch.
> 
> 
> One comment though - if I create the properties in SLOF, I have to name
> them different, like rtas-entry/rtas-base or slof,rtas-entry/slof,rtas-base
> to avoid colliding with the ones create by the guest kernel.

That's fine.  I don't know if the kernel will error if the properties
are already there or just overwrite them, but using new names might be
safer.

> So what do I name them? And do we need 2 copies of the same thing,

Need, no, but if having 2 copies is the simpler approach that's fine.

> do we
> ever expect rtas-entry!=rtas-base? The guest can potentially get them
> different (under powervm) but not with SLOF.

More to the point, qemu doesn't actually need to know the entry point
for the fwnmi stuff, only the base address.

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

signature.asc
Description: PGP signature