Date
21 - 24 of 24
Platform specification questions
|
Ved Shanbhogue
On Sun, Dec 12, 2021 at 7:55 PM Anup Patel <anup@...> wrote:I was thinking along the lines of how Greg was thinking here.Since, both OS-A platforms with M-mode and M platforms need ACLINT Agree. But for today's systems and for future systems that don't implement SstcAgree. regards ved |
|
|
|
Greg Favor
On Sun, Dec 12, 2021 at 7:55 PM Anup Patel <anup@...> wrote: On Mon, Dec 13, 2021 at 5:45 AM Vedvyas Shanbhogue <ved@...> wrote: Since, both OS-A platforms with M-mode and M platforms need ACLINT Here's a response from a different angle. MTIME matters to the SEE because it provides the timebase that is then seen by all harts in their 'time' CSRs (via the RDTIME pseudoinstruction). But if the initial OS-A platform specs are going to drop any M-mode standardization/etc., then it seems like the thing to do - from the SEE and OS-A platform perspectives - is to abstract MTIME as just the "system timebase that propagates to all harts and is seen by S/HS/U mode software in the form of the 'time' CSR" (just as the Unpriv spec does in its own words). Whatever would be said about MTIME and tick period constraints (e.g. a minimum tick period) would instead be expressed wrt this abstracted timebase - which the Unpriv spec refers to as "wall-clock
real time that has passed from an arbitrary start time in the past. .... The execution environment should provide a means of determining the period of a counter tick (seconds/tick). ...". This separates out from the current OS-A platform specs the ACLINT MTIMER device as a standardized Machine-level implementation of the MTIME and MTIMECMP registers defined in the Priv spec. Now, for systems that implement Priv 1.12 and the Sstc extension, and actually use the Sstc extension, then this can be the end of the story. But for today's systems and for future systems that don't implement Sstc (unless all OS-A 2022 platform specs were to mandate Sstc support and eliminate any possibility of existing systems complying with at least the Embedded (i.e. old "Base") OS-A platform spec), they also need the SBI API that provides Supervisor timer functionality to S/HS mode (with M-mode using MTIME and MTIMECMP to provide that functionality). While this is also an SEE interface, talking about this does start to sneak up on talking about MTIME. But then again one could still abstract MTIME as the system timebase, and MTIMECMP as a timebase compare value. Greg |
|
|
|
Hi Ved,
Please see comments inline below ... Regards, Anup On Mon, Dec 13, 2021 at 5:45 AM Vedvyas Shanbhogue <ved@...> wrote: 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 ...". 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. 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.
|
|
|
|
Ved Shanbhogue
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? 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. 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? 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 |
|
|