Re: [PATCH 1/1] RAS features for OS-A platform server extension
On Wed, Jun 23, 2021 at 7:59 AM Abner Chang <renba.chang@...> wrote:
To the extent that "RAS interrupts" are literally that, i.e. interrupt request signals, then they go to the system interrupt controller just like all other interrupt request signals. (Some system designs might also have a "platform microcontroller" that has its own local interrupt controller and may receive some of these interrupt request signals.)
Maybe part of what you're trying to get at is that RAS error events in many architectures get logged in and reported from hardware RAS registers. RAS registers "report" errors by outputting RAS interrupt request signals. Software then comes back around and reads the RAS registers to gather info about logged errors.
I expect RV will have similarities to ARM in this matter - and ARM doesn't have a hardware signal defined for triggering TEE either (and hasn't felt the need to define such).
Neither ARM nor RISC-V has a direct equivalent of SMM. So I'll pick on what ARM has - which is rather like RV. At a hardware level ARM has EL3 and Secure ELx, and RV as M-mode and secure partitions of S/U-mode (using PMP). At a software level one has a Secure monitor running in EL3/M-mode and tbd whether other parts run in SELx/partitions. TZ as a TEE is a combination of these hardware features and the secure software that runs on it. ARM TZ doesn't specify the actual software TEE, it just provides the hardware architectural features and framework for creating and running a TEE. There is no one standard ARM TEE (although ARM has developed their ATF as a reference secure boot flow; although maybe it has expanded in scope in recent years?).
In short, RV first needs to define, develop, and specify a software TEE. The hardware components are falling into place (e.g. PMP, ePMP, Zkr), and OpenSBI is working towards supporting secure partitions. So, until there is a concrete RISC-V TEE standard (or even a standard framework), we shouldn't be stating requirements tied with having a TEE. Also keep in mind that things like secure boot will be required in the Server extension - which is part of the overall topic of TEE.
What you describe, for RV, is M-mode - a pretty direct analog of ARM EL3.
RV has ECALL, just like ARM has SMC.
I think part of what complicates this discussion is the nebulous nature of what exactly is the "TEE" in any given architecture. At a hardware level x86/ARM/RV have SMM/EL3/M-mode and they have ways to "call" into that secure environment. The software TEE architecture is what is rather nebulous. There isn't a standard software TEE architecture for x86; RV doesn't have something (yet), and ARM has just ATF (which one may or may not fully equate to being a "TEE").