Error handling (kernel vs firmware first)

[andreiw]

Current language for BRS-I mentions firmware-first (APEI) handling. We need to close on whether that's really doable for v1 of the BRS or whether we should just remove any requirement on error handling implementation for now.

[dhaval-rivos]

Let us discuss in BRS but we have spec WIP already as part of RAS POC.

[adurbin-rivos]

Sounds like there are in-flight changes to ACPI and UEFI (CPER) to be tracked in PRS. @dhaval-rivos indicating we need these changes to have a more functional APEI. Time frame on these changes proposals?

[andreiw]

This is what I got back from Himanshu at Ventana: APEI doesn't require any additional hardware capabilities.

So there's some disagreement here. To be investigated.

[dhaval-rivos]

Hi Andrei, I am not exactly sure of what Himanshu meant, but unless I misunderstood the question, let me provide specific example why I said APEI/CPER changes are tied to HW. i.e. we have notification method for RAS events. This notification method is HW dependent (RAS exception). Similarly CPER table contains information that comes from RV HW. So if the question was we could define APEI/CPER independent of RERI spec being defined, I still think there is dependency.

[avpatel]

List of things required for APEI/CPER are:

• RAS Local IRQs which already standardized/ratified by AIA spec.
• RAS Non-maskable interrupts defined by RNMI spec which is in final stages.
• RAS exception codes will be standardized as part of Priv v1.13 spec by end-of this year

The APEI/CPER as being implemented for RISC-V RAS software stack are independent of RERI and the above mentioned dependencies will be resolved soon.

@hschauhan Please add if I missed anything.

[hschauhan]

The APEI only captures the information about how events are propagated. APEI doesn't depend on the hardware because I doesn't really deliver the event. The propagation is dependent on hardware but information about it is not. These two things are not same.

[dhaval-rivos]

Let us say we are proposing to have 2 different types of CPU error records (we briefly touched on it in our last sync). 1. Generic Processor Error Section. This one can be independent of RERI as information is fairly generic in nature. 2. Risc-V Processor Error record. This one is RV specific and it will take information from RERI and convey it to the OS. So as per my knowledge this will have RERI dependency. There is a follow up to our RAS POC discussion (and Spec changes) will schedule soon and we can arrive at a conclusion? =D

…

On Thu, Sep 14, 2023 at 10:59 AM Himanshu Chauhan ***@***.***> wrote: The APEI only captures the information about how events are propagated. APEI doesn't depend on the hardware because I doesn't really deliver the event. The propagation is dependent on hardware but information about it is not. These two things are not same. — Reply to this email directly, view it on GitHub <#71 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3DE7SFXFA7OZGLQ7ZEDOXTX2KI4DANCNFSM6AAAAAA4OHWSRE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Thanks! =D

[avpatel]

@dhaval-rivos We can always do APEI related ECRs incrementally. The first set of APEI related ECRs can be very basic having no dependency on HW specs.

[dhaval-rivos]

Hi Anup, Yes that is okay too. Another option was to add APEI related details later in BRS spec once we have conclusions on POC/RERI. I am not sure if it is critical to have these details in BRS right now (and who would benefit) when a lot of work is still happening. I think that was the original question. =D

…

On Thu, Sep 14, 2023 at 12:11 PM Anup Patel ***@***.***> wrote: @dhaval-rivos <https://github.com/dhaval-rivos> We can always do APEI related ECRs incrementally. The first set of APEI related ECRs can be very basic having no dependency on HW specs. — Reply to this email directly, view it on GitHub <#71 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3DE7SFHIQ2O7U4GCZ2DTG3X2KRIFANCNFSM6AAAAAA4OHWSRE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Thanks! =D

[andreiw]

So it sounds like there may be an AIA dependency (perhaps AIA thus implies compliance to the RAS), but yeah I see that the RAS specs are still in flight so we can hold our horses for sure...

[andreiw]

Deferring on this (but still keeping it around for context).