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 <da...@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 <aravi...@linux.vnet.ibm.com> > >>>>>> Reviewed-by: David Gibson <da...@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. > > > > 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
