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

[Alexey Kardashevskiy]

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.

So what do I name them? And do we need 2 copies of the same thing, do we
ever expect rtas-entry!=rtas-base? The guest can potentially get them
different (under powervm) but not with SLOF.


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



-- 
Alexey

signature.asc
Description: OpenPGP digital signature