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

Thanks.

https://github.com/riscv/riscv-isa-manual/pull/665 -Josh

I can and will do that. The point of raising this here is to explicitly confirm that the platform intent is to enable Memory PMA within, say, PCIe-managed regions. With that confirmation now

Signed-off-by: Kumar Sankaran <ksankaran@...> --- riscv-platform-spec.adoc | 42 ++++++++++++++++++++++++++-------------- 1 file changed, 27 insertions(+), 15 deletions(-) diff --git

It would be ideal if the CMO group could focus on fast-tracking the Cache Block Maintenance Operations for Phase 1 and get opcodes assigned, and this part of the specification frozen. The

Hi all, My apologies as I just got wind of this discussion (I was unable to attend the last few CMO TG meetings due to travel). I think we should sync up on the CMO TG and SBI/platform efforts since

This sentence is fraught with use of a few ill-defined terms, e.g. "regular main memory" and "device scratchpad RAMs" - which for now maybe isn't worth trying to "fix". I would suggest making a PR on

The conflict is that statement in the priv. spec suggests that things like "device scratchpad RAMs" like those that might be in PCIe land "are" I/O, in that they are not Memory. Moving that priv

Hi Mayuresh, As I mentioned in the platform meeting, we missed the requirement for firmware. I added in below section and please rephrase it if you want. Regards, Abner Mayuresh Chitale

Yes, most likely IOPMP can be used to do this. That would be appropriate. And, for example, one much simpler implementation approach (than the IOPMP proposals) would be to replicate a CPU PMP block

This is for outbound traffic and, if one sets aside the word "I/O" in the proposed text saying "two I/O regions for mapping ..." (e.g. replacing "I/O" with "address"), then is there a conflict? The

I understand that IOPMP is not an IOMMU, but to the extent that it is a general "bus master memory protection" widget, it can be used by M-mode to ensure simple things, such as that