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

[Alexey Kardashevskiy]

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.

> or we'll need to resurrect
> Aravinda's original UPDATE_RTAS hcall.





-- 
Alexey

signature.asc
Description: OpenPGP digital signature