[Skiboot] [RFC PATCH] powerpc/powernv: report error messages from opal

[Oliver]

On Fri, Jul 7, 2017 at 10:28 AM, Stewart Smith
<stewart at linux.vnet.ibm.com> wrote:
> Michael Ellerman <mpe at ellerman.id.au> writes:
>> Stewart Smith <stewart at linux.vnet.ibm.com> writes:
>>> Oliver O'Halloran <oohall at gmail.com> writes:
>>>> diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
>>>> index 0e2e57bcab50..cb9c0e6afb33 100644
>>>> --- a/arch/powerpc/include/asm/opal-api.h
>>>> +++ b/arch/powerpc/include/asm/opal-api.h
>>>> @@ -167,7 +167,8 @@
>>>>  #define OPAL_INT_EOI                               124
>>>>  #define OPAL_INT_SET_MFRR                  125
>>>>  #define OPAL_PCI_TCE_KILL                  126
>>>> -#define OPAL_LAST                          126
>>>> +#define OPAL_SCRAPE_LOG                            128
>>>
>>> (another thought, along with the skiboot thoughts), I don't like the
>>> SCRAPE_LOG name so much, as it's more of a "hey linux, here's some log
>>> messages from firmware, possibly before you were
>>> involved"... OPAL_FETCH_LOG ?
>>
>> I'm not a huge fan of an interrupt followed by an opal call just to
>> fetch a single line of log.
>>
>> Can't we do something more like the existing msglog code, where we have
>> a ring buffer and then the interrupt just becomes "hey Linux you should
>> look at your ring buffer".
>
> Yeah... that would probably be a bit better...
>
> Although that would mean we can only ever tell the running kernel what's
> in the ring buffer. We couldn't work out a way to (after kexec) resend
> important bits of info such as "we garded things out, your OCC didn't
> start and we trained everything at really slow speeds"

Isn't this is the use case for BMC based error logs? A ring buffer is
fundamentally a structure for transient data. There's no real way to
hack in permanence other than making sure that making sure it never
fills.