Hi Paul, Everyone over here is well aware of the importance of fast-tracking basic CMO instructions and getting it frozen soon. The CMO group is also aware of their priorities so we should let

Thanks.

https://github.com/riscv/riscv-isa-manual/pull/665 -Josh

I can and will do that. The point of raising this here is to explicitly confirm that the platform intent is to enable Memory PMA within, say, PCIe-managed regions. With that confirmation now

Signed-off-by: Kumar Sankaran <ksankaran@...> --- riscv-platform-spec.adoc | 42 ++++++++++++++++++++++++++-------------- 1 file changed, 27 insertions(+), 15 deletions(-) diff --git

It would be ideal if the CMO group could focus on fast-tracking the Cache Block Maintenance Operations for Phase 1 and get opcodes assigned, and this part of the specification frozen. The

Hi all, My apologies as I just got wind of this discussion (I was unable to attend the last few CMO TG meetings due to travel). I think we should sync up on the CMO TG and SBI/platform efforts since

This sentence is fraught with use of a few ill-defined terms, e.g. "regular main memory" and "device scratchpad RAMs" - which for now maybe isn't worth trying to "fix". I would suggest making a PR on

The conflict is that statement in the priv. spec suggests that things like "device scratchpad RAMs" like those that might be in PCIe land "are" I/O, in that they are not Memory. Moving that priv

Hi Mayuresh, As I mentioned in the platform meeting, we missed the requirement for firmware. I added in below section and please rephrase it if you want. Regards, Abner Mayuresh Chitale

Yes, most likely IOPMP can be used to do this. That would be appropriate. And, for example, one much simpler implementation approach (than the IOPMP proposals) would be to replicate a CPU PMP block

This is for outbound traffic and, if one sets aside the word "I/O" in the proposed text saying "two I/O regions for mapping ..." (e.g. replacing "I/O" with "address"), then is there a conflict? The

I understand that IOPMP is not an IOMMU, but to the extent that it is a general "bus master memory protection" widget, it can be used by M-mode to ensure simple things, such as that

I'm not sure if an IOPMP could be used for this particular purpose, but more generally IOPMP is being driven by embedded people and isn't consciously thinking about functionality requirements implied

The proposal allows for prefetchable BARs to be programmed to support as I/O or Memory. This seems to conflict with the priv spec that states: """ Memory regions that do not fit into regular main

Is this an M-mode SW requirement or a HW requirement that these interrupts are delegatable (writeable) in HW? Why require the delegation by M-mode instead of allowing for M-mode to trap and pass down?

While potentially a fine goal, it seems that to make this happen in a manner that allows Platform-compliant SW to be portable, more needs to be done beyond the Zicmobase work, at least in terms of

I have already sent questions to Andrew to get the official view as to the intent of this aspect of the Priv spec and what is the proper way or perspective with which to be reading the ISA specs.

If this is an issue with the priv spec please add it to the priv spec github issues. thanks Mark

Priv: """ Accesses by one hart to main memory regions are observable not only by other harts but also by other devices with the capability to initiate requests in the main memory system (e.g.,