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.
Thanks,
James
