Hi Ved,

Please see comments inline below ...

Regards,
Anup

On Mon, Dec 13, 2021 at 5:45 AM Vedvyas Shanbhogue <ved@...> wrote:

Greetings All!

Please help with the following questions about the OS-A/server extension:
Section 2.1.4.1 - Timer support:
Should the ACLINT MTIMER support should be optional or moved into the M-platform section or made optional for the server extension?

The RISC-V Privileged v1.12 defines MTIME and MTIMECMP as platform
specific memory-mapped registers in "Section 3.2 Machine-Level
Memory-Mapped Registers". This means the RISC-V platform specification
needs to standardize memory layout and arrangement of the MTIME and
MTIMECMP memory-mapped registers which is what ACLINT MTIMER
specification does.
(Refer, https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf)

Since, both OS-A platforms with M-mode and M platforms need ACLINT
MTIMER so I suggest that OS-A platforms should say "If M-mode is
implemented then ACLINT MTIMER should be supported ...".

Section 2.1.4.2.4:
"Software interrupts for M-mode, HS-mode and VS-mode are supported using AIA IMSIC devices". Is the term "software interrupt" here intended to be the minor identities 3, 1, and 2? If so please clarify what the support in IMSIC is expected to be for these minor identities.

The AIA IMSIC devices do not provide interrupts via minor identities
3, 1, and 2. Both AIA IMSIC and APLIC devices only deal with minor
identities 9, 10, and 11 (i.e. external interrupts) whereas the ACLINT
specification defines devices that deal with minor identities 1, 3,
and 7.

For software, the "inter-processor interrupts" (at M-mode or S-mode)
can be implemented:
1) Using ACLINT MSWI or SSW devices
OR
2) Using AIA IMSIC devices

I think the confusion here is because the RISC-V platform
specification uses the term "software interrupt" for both
"inter-processor interrupt" and "minor identities 3, 1, and 2". I
suggest using the term "inter-processor interrupt" at most places and
only use the term "software interrupt" in-context of ACLINT MSWI or
SSWI devices.

Section 2.1.7.1:
Is supporting SBI TIME optional if the server extension is supported as server extension requires Sstc? Is supporting SBI IPI optional if AiA IMSIC is supported?

I agree, this text needs to be improved because now Base and Server
are separate platforms. Since, the Server platform mandates IMSIC and
Priv Sstc extension so SBI TIME, IPI and RFENCE can be optional but
this is not true for the Base platform.

Section 2.3.7.3.2 - PCIe memory space:
The requirement to not have any address translation for inbound accesses to any component in system address space is restrictive. If direct assignment of devices is supported then the IOMMU would be required to do the address translation for inbound accesses. Further for hart originated accesses where the PCIe memory is mapped into virtual address space there needs to be a translation through the first and/or second level page tables. Please help clarify why PCie memory must not be mapped into virtual address space and why use of IOMMU to do translation is disallowed by the specification.

Section 2.3.7.3.3 - PCIe interrupts:
It seems unnecessary to require platforms built for the '22 version of the platform to have to support running software that is not MSI aware. Please clarify why supporting the INTx emulation for legacy/Pre-PCIe software compatibility a required and not an optional capability for RISC-v platforms?

Section 2.3.9:
For many platforms especially server class platforms SECDED-ECC is not sufficient protection for main memory. Why is the platform restricting a platform to only support SECDED-ECC? Is it a violation of the platform specification if the platform supports stronger or more advanced ECC than SECDEC-ECC?

Which caches are/should be protected and how is usually a function of the technology used by the cache, the operating conditions, and the SDC/DUE goals of the platform and are established based on FIT modeling for that platform. Please clarify rationale for requiring single-bit error correction on all caches? Also please clarify why the spec dont allow for correcting multi-bit errors; based on the SDC goals some caches may need to support for e.g. triple error detection and double error correction..

The firmware-first model seems to require a configuration per RAS-event/RAS-error-source to trigger firmware-first or OS-first. There may be hundreds of RAS events/errors that a platform supports. Why is it required to support per-event/per-error selectivity vs. a two level selection where all RAS errors are either handled by firmware-first or handled by OS-first.

regards
ved