[SLOF] [PATCH slof] rtas: Reserve space for FWNMI log

[Thomas Huth]

On 27/08/2019 03.39, Alexey Kardashevskiy wrote:
> 
> 
> On 26/08/2019 22:29, Thomas Huth wrote:
>> On 26/08/2019 05.44, Alexey Kardashevskiy wrote:
>>> The Firmware Assisted Non-Maskable Interrupts Option (FWNMI) feature
>>> requires some space for RTAS log which is in the RTAS blob area.
>>>
>>> This expands the RTAS blob size to 2k.
>>>
>>> More details here: https://patchwork.ozlabs.org/patch/1146765/
>>
>> Ouch, that sounds like an very fragile interface. Is this mandated by
>> sPAPR that we have to put the log into the RTAS region?
> 
> 
> This is my understanding, yes. Aravinda can correct me if I am wrong.
> QEMU uses a fixed offset of 0x30 into this area to decide where the log
> starts. Not perfect but the frequency of RTAS changes (which a naught)
> assumes we are quite safe here.
> 
>>
>>> Signed-off-by: Alexey Kardashevskiy <aik at ozlabs.ru>
>>> ---
>>>   lib/libhvcall/hvcall.S | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/lib/libhvcall/hvcall.S b/lib/libhvcall/hvcall.S
>>> index b19f6dbeff2c..adcda0dd905d 100644
>>> --- a/lib/libhvcall/hvcall.S
>>> +++ b/lib/libhvcall/hvcall.S
>>> @@ -134,6 +134,7 @@ ENTRY(hv_rtas)
>>>       ori    r3,r3,KVMPPC_H_RTAS at l
>>>       HVCALL
>>>       blr
>>> +    .space 2048 - (. - hv_rtas)
>>>       .globl hv_rtas_size
>>>   hv_rtas_size:
>>>       .long . - hv_rtas;
>>> @@ -144,6 +145,7 @@ ENTRY(hv_rtas_broken_sc1)
>>>       ori    r3,r3,KVMPPC_H_RTAS at l
>>>       .long    0x7c000268
>>>       blr
>>> +    .space 2048 - (. - hv_rtas_broken_sc1)
>>>       .globl hv_rtas_broken_sc1_size
>>>   hv_rtas_broken_sc1_size:
>>>       .long . - hv_rtas_broken_sc1;
>>>
>>
>> Can you please at least add some comments to the code which explain the
>> padding - otherwise it's pretty impossible to understand when you look
>> at the code later.
> 
> Sure can do that, how about:
> 
> /*
>  * A space reserved for a RTAS log from Firmware Assisted
>  * Non-Maskable Interrupts Option (FWNMI) feature.
>  *
>  * The QEMU implementation uses 0x30..0x800 for the log.
>  */

Sounds good, yes.

 Thomas