Given where we are currently with the lack of a proper definition for TEE, I suggest we simply remove the requirement for TEE for now and add it later when the TEE spec is finalized. Suggest we remove

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

Greg Favor <gfavor@...> 於 2021年6月23日 週三 上午9:51寫道： Agreed. Does this mean the interrupt controller would integrate all RAS events (HART, PCI, I/O, memory and etc.)? Or there

Yes. Which is just a software matter of configuring the interrupt controller accordingly. Agreed. The details and mechanics don't need to be discussed (unless they are mandating specific mechanics

Greg - Do you have any further comments/responses to Abner's comments below? Abner - my comments inline below. I think the primary requirements here are the following: - The platform should provide

I suggest adding PENDING SET and PENDING CLR registers to implement a soft plic irq mechanism, here. PENDING SET: only '1' bits of the value would be set into reg and '0' bits of the value would be

From: Abner Chang <abner.chang@...> This is the commit for creating the patches for widely review in Platform Spec HSC task group Signed-off-by: Abner Chang <abner.chang@...> ---

From: Abner Chang <abner.chang@...> As Atish mentioned in the meeting, resend the patch to this task group for the widely review becasue this document is referred in RISC-V platform spec. Abner

Thanks. This does seem to be all a matter of software configuring and handling things appropriately. Then this just becomes a matter of software configuring the interrupt controller to direct a

Greg Favor <gfavor@...> 於 2021年6月18日 週五 上午2:03寫道： That could be, - If RAS error triggers M-mode (FFM) and firmware decides to expose the error to OS (could be configured through

Here's the results of my Q&A with Andrew: - The Priv (and Unpriv) ISA specs are just that. They are CPU architecture specs and should be read with that limited scope in mind. They may touch on

Good answers all around; I didn't pick up on the difference between OS-A base and OS-A server difference. It makes sense in hindsight for the manufacturers to set the MTBF goal and design to meet it.

To add to what Greg mentioned below, the RAS features as mentioned in the patch is required only for the OS-A platform server extension. We are not mandating any RAS requirements for the OS-A base

Nowadays single-bit errors are far from rare. There will always be people that run Linux and are willing to accept occasional silent corruptions and whatever mysterious application/data corruptions

Is it acceptable to everyone that all single bit errors on all caches must be correctable? That really affects designs in fundamental ways for L1 caches (as opposed to simply detecting). Not as big a

I would have thought that this is just a software issue. What kind of hardware mechanism do you picture being needed? By "mask" do you mean masking of generation of an error interrupt? Wouldn't

Kumar Sankaran <ksankaran@...> 於 2021年6月16日 週三 上午8:17寫道： Hi Kumar, I would like to add something. In order to support the OEM RAS policy, - The platform should provide the

Arch-test should be involved also. It is (more than) a bit complicated because CMOs are instructions that affect non-architectural bits of an implementation - so it's unclear what it even means to

FWIW, our (the CMO TG's) priorities are in order as follows: - Zicbom (maintenance) - Zicboz (zero) - Zicbop (prefetch) We happen to have provisional opcodes for both Zicbom and Zicboz (mostly since

Hi Paul, Everyone over here is well aware of the importance of fast-tracking basic CMO instructions and getting it frozen soon. The CMO group is also aware of their priorities so we should let