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

[Alexey Kardashevskiy]

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>;
[...]


-- 
Alexey