In re. your other question: > Another question: are CSRs also memory mapped? In debug mode? No, CSRs are not specified as memory-mapped (an implementation may choose to do so), even in Debug

It's something that could conceivably be standardized by the Unix platform task group, but I'm unaware as to whether that's in their plan of record.

Thanks Andrew - yes this de facto is great information. Is there any platform-level effort to convert this to a standard? Best Regards Nagendra

The memory map isn't in the spec because it's platform-defined. Some folks use the SiFive CLINT as a de facto standard for the address map for mtime[cmp] and MSIP registers. QEMU supports this as

Dear team, This may be a basic question: I am trying to figure out where in the physical memory map are the "mtime" and "mtimecmp" registers to be placed. Per the privileged spec, these registers are

I agree with this one example. But I'm also trying to address the broader issue and ask the more general architecture-level question (that I originally stated), i.e. must new implementations that

If hstatus.SPV=0, then SRET behaves like normal. And since that bit will stay zero unless some code messes with hypervisor CSRs, it should be sufficient to just have the reset state initialize it that

But there is existing architecture functionality (e.g. the SRET instruction) that is affected by certain bits in a hypervisor CSR - which would be in effect because of misa.H=1. If it was just a

Why would that be a problem? As long as you don't issue any HS-mode instructions or touch any of the hypervisor CSRs then any code should run the same. Jonathan

One issue is that the current Privileged spec requires that misa.H is reset to '1' if the Hypervisor extension is implemented. Unaware boot code will leave that set and then problems will ensue

I would expect the rule be that either the reset state properly initializes all the H-extension CSRs or the boot code. Thus if you want hardware to be backwards compatible with legacy boot code, you

We have run across the situation of running "legacy" (i.e. current) boot code that naturally is unaware of the possible existence of the Hypervisor extension. Since, on a platform that does implement

The Hypervisor extension adds bits to some of the existing M-mode CSR's. When this extension is not implemented, these bits are hardwired to zero. When the extension _is_ implemented these bits

yes, fair enough. Leaving it unrestricted is certainly the most flexible way Tariq

The only reason that you might want to enforce some ordering is just so setup code doesn't have to check every single entry to see if it's writable or not. That is not a great reason for something

I've merged the pull request, but comments are obviously still welcome. I recommend adding them on github at https://github.com/riscv/riscv-isa-manual/pull/525 to reduce the likelihood that they get

Hardwired nonzero PMP registers are likely to start at the zeroth entry, because that way they have highest priority. If they came at the end, writable PMPs could override them. Once we admit that

I don’t think I understand the your comment, Andrew. I interpreted Tariq saying we essentially restrict RdOnly zero entries to always be the larger numbered ones. (Sort is the way that HartIndexes

I see what you're getting at, but since some vendors will (rightly) choose to hardwire some PMP registers, the sentiment seems impractical to enforce.

Thanks for this Andrew, it’s really useful. My only comment is: “Up to 64 PMP entries are supported. Implementations may implement zero, 16, or 64 PMP CSRs. All PMP CSR fields are WARL and