FWIW, although I appreciate the motivation behind this requirement, I also support removing it. For the case that mtime is centrally implemented, this requirement is quite onerous to implement. For

Hi there, In the OS-A platform spec I see the following requirement: • dcsr.stopcount and dcsr.stoptime must be supported and the reset value of each must be 1 The rationale justifies the

Greg HI - Thanks. I think this is very clear. I think the recommendation could be changed to require MSI and make supporting INTx emulation optional. I am hoping to hear from BIOS and OS experts if

As per the discussion and agreement during the Platform HSC meeting, this patch splits the content of the platform spec into 3 different sections - an OS-A Common Requirements section, OS-A Embedded

The following two items in Ved's email didn't get any response, so I offer my own below ... I think where this came from is learnings in the ARM "server" ecosystem (as then got captured in SBSA). In

Yes, fine by me. We can make the changes you have suggested above and leave the remaining content as is. -- Regards Kumar

Kumar & Greg, If the content is worthwhile, please consider putting it in an informative section. Content, such as discussed, might either become an (inline) application note—or go into a separate

So we could drop these statements: " - Main memory must be protected with SECDED-ECC. - All cache structures must be protected. - single-bit errors must be detected and corrected. - multi-bit

The intent of the platform spec is hardware-software interoperability. I agree that dictating RAS hardware features is not within the scope of the platform spec. However, we do want standards for RAS

I wouldn't view platform mandates of this sort as teaching, but as establishing a baseline that system integrators can depend on - by guiding the hardware developers as to what that expected baseline

I agree. I think the RAS ISA would want to be about standardized error logging and reporting but not mandate what errors are detected/corrected and how they are corrected or contained. For example,

This was just trying to mandate a basic requirement and not go as far as requiring protection of all RAM-based structures - which some may view as overreach. Conversely I can understand that some

Totally agree that the term "cache structure" is ambigous and variety of caches may be built. How caches are built should also be transparent to the ISA, software, and the platform in general. Like

This seems like a toothless and qualitative mandate since no FIT requirements are specified. It can be a suggestion, although it's just a qualitative suggestion. It's essentially just saying "don't

Will be glad to. Yes, that sounds good. regards ved

Thanks Ved. Minor nits below. Would you be OK to send out a patch to the mailing list for these 3 changes and then subsequently a PR to the platform git on github? Let me know if you need any help

We should have a table with dependencies for SBI extensions. E.g. SBI Time only required if sstc is not present SBI IPI/RFENCE is only required if IMSIC or SSWI is not present I will send a patch

Thanks. Yes. Could I suggest: "Cache structures must be protected to address the Failure-in-time (FIT) requirements. The protection mechanisms may included single-bit/multi-bit error detection and/or

Agree. The intent here was to mandate a minimal set of memory protection features for server class platforms. It is not a violation of the platform spec to have something better. As per the

Yes, as per our agreement during the Platform HSC meeting several weeks back, the plan is to make the OS-A Embedded and OS-A Server as individual platforms without any relationship to each