[lkml]   [2017]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt
    Hi Wang Xiongfeng,

    On 18/04/17 02:09, Xiongfeng Wang wrote:
    > I have some confusion about the RAS feature when VHE is enabled. Does RAS spec support
    > the situation when VHE is enabled. When VHE is disabled, the hyperviosr delegates the error
    > exception to EL1 by setting HCR_EL2.VSE to 1, and this will inject a virtual SEI into OS.

    (The ARM-ARM also requires the HCR_EL2.AMO to be set so that physical SError
    Interrupts are taken to EL2, meaning EL1 can never receive a physical SError)

    > My understanding is that HCR_EL2.VSE is only used to inject a virtual SEI into EL1.

    ... mine too ...

    > But when VHE is enabled, the host OS will run at EL2. We can't inject a virtual SEI into
    > host OS. I don't know if RAS spec can handle this situation.

    The host expects to receive physical SError Interrupts. The ARM-ARM doesn't
    describe a way to inject these as they are generated by the CPU.

    Am I right in thinking you want this to use SError Interrupts as an APEI
    notification? (This isn't a CPU thing so the RAS spec doesn't cover this use)

    This is straightforward for the hyper-visor to implement using Virtual SError.
    I don't think its not always feasible for the host as Physical SError is routed
    to EL3 by SCR_EL3.EA, meaning there is no hardware generated SError that can
    reach EL2. Another APEI notification mechanism may be more appropriate.

    EL3 may be able to 'fake' an SError by returning into the appropriate EL2 vector
    if the exception came from EL{0,1}, or from EL2 and PSTATE.A is clear.
    If the SError came from EL2 and the ESR_EL3.IESB bit is set, we can write an
    appropriate ESR into DISR.
    You cant use SError to cover all the possible RAS exceptions. We already have
    this problem using SEI if PSTATE.A was set and the exception was an imprecise
    abort from EL2. We can't return to the interrupted context and we can't deliver
    an SError to EL2 either.

    Setting SCR_EL3.EA allows firmware to handle these ugly corner cases. Notifying
    the OS is a separate problem where APEI's SEI may not always be the best choice.



     \ /
      Last update: 2017-04-18 12:56    [W:7.110 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site