search

riscv-non-isa / iopmp-spec

This repository contains the specification source for the RISC-V IOPMP Specification. This document proposes a Physical Memory Protection Unit of Input/Output devices, IOPMP for short, to regulate the accesses issued from the bus masters.
https://jira.riscv.org/browse/RVG-56
Creative Commons Attribution 4.0 International
15 stars 4 forks source link

Questions regarding TOR as the first entry #16

Closed YazanHussnain-10x closed 1 month ago

YazanHussnain-10x commented 1 month ago

Section 2.5 of the IOPMP Spec: Since the address encoding scheme of TOR refers to the previous entry’s memory region, which is not in the same memory domain, it would cause two kinds of unexpected results. If the first entry of a memory domain selects TOR, the entry refers to the previous memory domain. When the previous memory domain may change unexpectedly, the region of this entry will be altered. To prevent the unexpected change of the memory region, one should avoid adopting TOR for the first entry of a memory domain. The second issue is that the memory region of the last entry is referred to by the next memory domain. To avoid this, one can set an OFF for the last entry of a memory domain with the maximal address.

Question 1 It makes sense that one should avoid adopting TOR for the first entry of a memory domain (MD). But why should the last entry of the MD be set to OFF? Since the last entry of the MD can only be referenced by the next MD if the first entry of the following MD is TOR (correct me if I’m wrong), one should adopt only one of the solutions, not both.

Question 2 If the IOPMP setting specifies that the first entry of the MD is not TOR and the second entry is TOR, and later the first entry of the corresponding MD is dissociated from the MD, leaving TOR as the first entry, what should be done in this case? I assume there would be no issue as long as the dissociated entry is not associated with another MD. But what if it is associated with a different MD?

tyshyu commented 1 month ago

I remember the descriptions are programming notice. Solutions in the descriptions are controlled by software.

Feedback of Question 1: I also agree only one of the solutions should be adopted in software implementation. It seems to me that the solutions fix the same issue.

Feedback of of Question 2: The case might has same issue as the aforementioned descriptions of Section 2.5. Proper software implementation can prevent the case. If the case is during reprogramming an IOPMP, I think it could be temporarily allowed when the IOPMP stalls transactions which is associated with the both MDs, and it is expected to be fixed by one of the solutions in Section 2.5 before the IOPMP resumes the stall.

YazanHussnain-10x commented 1 month ago

@tyshyu Thanks for clarification.