- [PATCH 1/1] RAS features for OS-A platform server extension
Re: [PATCH 1/1] RAS features for OS-A platform server extension
Do we need to define what is the RAS error signals output to the interrupt controller? (The signal could be classified by
the error severities such as CE, UC_FATAL, UC_NONFATAL or classified by the RAS error categories such as RAS_MEM_ERROR, RAS_IO_ERROR and etc.)
This just starts down the path of defining a small bit of a RAS architecture - which we shouldn't do without developing a full RAS architecture is developed (next year).
I think we can just leave it to RAS TG because we just define what server platform needs on RAS, right?
Without the hardware signal to trigger TEE. The alternative would be triggering the M-mode exception and jump to TEE in the M-mode exception handler?
So the scenario of triggering TEE would be,
For software management mode interface:
S-mode-> sbi ecall to M-mode->TEE jump vector->TEE
Effectively the same as with ARM.
For the hardware management mode interface:
Hardware interrupt -> M-mode handler->
TEE jump vector->TEE
What firmware or software resides in TEE is implementation-specific. For example on edk2, we will load the management mode core into TEE.
I am just trying to get more understanding of the future design of TEE on RV.
I think the tech-tee TG has done some pieces of things around TEE, but I'm not sure what (and certainly there isn't anything heading to ratification this year).
Join firstname.lastname@example.org to automatically receive all group messages.