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'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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

A bit more on that. There are a few debug CSRs which can be accessed as both CSRs and as Debug registers, specifically for communication. Otherwise, debug registers are in their own address space, and

Can someone provide a definitive answer (Andrew?) as to the architectural intent of whether implementations supporting new architecture extensions must maintain backward compatibility with "legacy" M

It certainly has been a goal, e.g., the CLIC was designed so that M-mode software that's oblivious to the CLIC still runs correctly on systems with the CLIC. I don't think there's a clear statement of