search

riscv / riscv-j-extension

Working Draft of the RISC-V J Extension Specification
https://jira.riscv.org/browse/RVG-128
Creative Commons Attribution 4.0 International
159 stars 18 forks source link

Zjpm: Definition of implicit access #18

Closed deepak0414 closed 5 months ago

deepak0414 commented 1 year ago

Chapter 2.1 calls out and reference a definition for effective address from base ISA. It also coin a term "implicit access". Spec gives an example of page walk as implicit access but doesn't really define. May be we should formally define what is an "implicit access".

pdonahue-ventana commented 1 year ago

This same term and similar terms like "implicit memory access" and "implicit read" are used several times in the privileged spec. If the meaning is unclear then maybe the definition should be introduced in that spec rather than this extension.

deepak0414 commented 1 year ago

In priv spec, term implicit access is used more in terms of local paragraph and understanding.

Here this term is quite ambiguous and vague which can be interpreted differently by different vendors and thus implemented differently.

As an example, is an instruction fetch (due to an interrupt/exception) from address programmed in stvec is an implicit access or not?

From technical perspective what's the difference between "implicit access" due to a page table walk v/s "implicit access" of an instruction fetch from address pointed to by stvec

The way I see it PM is mostly revolving around when paging is enabled (definitions of NVBITS, VBITS, etc). It would be more appropriate & unambiguous to say that all virtual memory accesses will be subject to PM and all physical accesses will not be subject to PM (when paging is enabled, all physical accesses become implicit by default)

This gets complicated when M mode is enabled (where there is no paging) but we still want PM in M mode. How is implicit access to address (in case of interrupt/exception in M mode) pointed to by mtvec is different from implicit access to page table structures in S/U mode (which're also physical addresses and not virtual)

martinmaas commented 1 year ago

I added more details about which accesses are affected in fd7220807e1405ba9b5de38d9d4ac26e73312128 (Section 2.6).

deanliberty5 commented 1 year ago

Sorry, but I didn't really find the clarifications... clarifying. Saying that "The transformation does not apply to implicit accesses such as page table walks" leaves me scratching my head, since an explicit access that misses in the TLB does go through a page table walk.

What exactly is it that doesn't go through the transformation? Addresses generated after the initial address transformation (such as addresses generated during PTWs)?

martinmaas commented 11 months ago

I think the latest spec clarifies these issues, but want to make sure to confirm before closing this issue. Section 2.6 now has a detailed discussion about which instructions have pointer masking applied. The important bit is that what gets transformed is the effective address of explicit instructions, so if an access is not to an address that is specifically (either directly or indirectly) provided by an instruction, pointer masking does not apply.