On Fri, Jun 25, 2021 at 4:31 PM Jonathan Behrens <behrensj@...
Requiring ASID support without specifying the number of bits means that even 1-bit ASIDs would be allowed, even though they'd be essentially useless. That said, I don't have a strong feeling about a particular number of bits to pick. Some software designs can get by on 4 bits, while others may benefit from 8 or even 16.
Is there anyone who would object to mandating the full 16 ASID bits for the Server Extension of the OS-A platform? I'm a software person so I really don't have a good sense of whether more bits would meaningfully increase costs/complexity.
Significant HW cost in TLBs.
My take is we should avoid imposing this requirement altogether. Kernel software needs to support the no-ASID case, anyway, so we aren’t simplifying software by imposing this requirement.
On Fri, Jun 25, 2021 at 4:55 PM Kumar Sankaran <ksankaran@...
Regarding ASID and VMID support, we are mandating those only for the Server Extension within the OS-A platform and not for OS-A platform base.
We could consider a minimum of 12-bits for the ASID support for the server extension, but then most server platforms would in reality only implement 4 bits of ASID. So simply mandating ASID support without any additional requirement seemed to be the best approach.
Is there any particular number of ASID bits you suggest for the server extension? Same for the VMID as well.
Regarding your second comment, yes, I agree that implementations shouldn’t be allowed to “fake” ASID support by clearing the entire TLB when the ASID changes. This will be a big performance penalty. Having said that, the approach the platform spec takes is to have a minimal set of features for hardware and software compatibility without mandating any performance requirements. So we can add the below line as an Informational or Application Note below the requirement. If you have an alternative wording for this line, feel free to send that over.
Is this supposed to include more detail than just "ASID support" and "VMID support"? Not sure if those are just placeholder section headings for now, but I'd expect to at least see a requirement of how many bits are required for each.
Also not entirely sure how to specify it, but it would be really nice if implementations weren't allowed to have "fake" ASID support by just clearing the TLB whenever the ASID changes. That's the strategy QEMU uses (at least the last time I checked) and it has the impact of leading to worse performance than not having ASIDs at all.
This patch adds the following
Cache coherency and ASID requirements
Interrupt Controller and PMU chapter sub-sections for OS-A base and
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ea6d5..b985f50 100644
@@ -88,8 +88,12 @@ The M platform has the following extensions:
* ISA Profile
** The OS-A platform is required to comply with the RVA22 profile.
* Cache Coherency
+** All HART related caches must be hardware coherent and must appear to
+software as Physically Indexed, Physically Tagged (PIPT) caches
+** Memory accesses by I/O masters can be coherent or non-coherent with respect
+to the HART related caches
The OS-A base platform requirements are -
@@ -287,10 +291,12 @@ base with the additional requirements as below.
The platforms which conform to server extension are required to implement +
-- RISC-V Hypervisor-level H Instruction-Set Extensions
-- IOMMU with support for memory resident interrupt files
+- RV64 support
+- RISC-V H ISA extension
+- ASID support
+- VMID support
The OS-A server platform requirements are all of the base above plus:
@@ -305,6 +311,8 @@ above.
respect to all harts connected to the DM
* Rationale: Debuggers must be able to view memory coherently
+==== Interrupt Controller
==== Boot and Runtime Requirements
The boot and system firmware for the RV64I server platforms required to be