search

riscv-non-isa / riscv-iommu

RISC-V IOMMU Specification
https://jira.riscv.org/browse/RVG-55
Creative Commons Attribution 4.0 International
98 stars 17 forks source link

Question about icvec behavior in WSI mode #299

Closed viktoryou closed 7 months ago

viktoryou commented 7 months ago

From my understanding, it is software's responsibility to program an interrupt vector for each interrupt cause. Then in MSI mode, we use the vector as an index into msi_cfg_tbl to determine the MSI to generate.

However, in WSI mode, the interrupt lines can be implied by ipsr(pip, pmip, fip, cip). The function of icvec makes me confused. If a cause can be given a unique vector, whether it is hardware's part to update icvec to distinguish the subsets of the interrupt signals? If not , how would sofware configure the icvec? I cound not figure it out well from the model or spec.

Additionally, since the mapping from subsets of interrupt cause to vector is not defined, I understand this is platform-defined, is it right? Furthurmore, is there any priority information implied by the interrupt vector, like the less of the vector, the higher is the priority?

ved-rivos commented 7 months ago

The IOMMU has 4 interrupt causes - command queue, page queue, fault queue, and HPM. These are represented by the 4 bits cip, pip, fip, and pmip in the ipsr register. For each of these causes, the icvec provides the facility to determine either a mapping to a MSI address/data pair (when MSI mode is active) or a wire (when WSI mode is active).

So effectively one could consider the icvec as a switchbox and can be visualized as follows: image

For WSI, this provides the flexibility to either map each interrupt cause to a different wire, map all causes to same wire, or share a wire for a subset of interrupt causes. Likewise for MSI, this provides the flexibility to map each interrupt cause to a different address/data pair, map all causes to a single address/data pair, or share a address/data pair for a subset of interrupt causes.

The step 9, 10, and 11 of the section 6.2 provide the guideline for configuring the icvec.

In case of WSI, the wires connect to a wired interrupt controller - such as the APLIC - and the the interrupt controller needs to be further programmed with additional interrupt related configuration such as edge/level trigger, interrupt domain, target, priority, etc.

viktoryou commented 7 months ago

Thanks for clarification. The diagram helps a lot. Here is my conclusion and I would like to double confirm with you: (1) icvec is purely configured by software; (2) mapping would be based on the interrupt type level(cip, fip, pip, pmip), the sub-type level(fence_w_ip/cmd_ill/cmd_to/cqmf in CQ and so on...) would be implied by ipsr.cip->cqcsr, or ipsr.fip->fqcsr and so on...

ved-rivos commented 7 months ago

(1) icvec is purely configured by software;

Yes

(2) mapping would be based on the interrupt type level(cip, fip, pip, pmip), the sub-type level(fence_w_ip/cmd_ill/cmd_to/cqmf in CQ and so on...) would be implied by ipsr.cip->cqcsr, or ipsr.fip->fqcsr and so on...

Right. Each interrupt source to ipsr - CQ, FQ, PQ, HPM - may have multiple reasons to assert the interrupt and those are recorded in their corresponding status registers. When an interrupt from CQ/FQ/PQ/HPM unit is observed, SW should read the cqcsr/fqcsr/pqcsr/iocountovf respectively to to determine the reason and handle appropriately. The section 6.5 provides more information.

18772820305 commented 5 months ago

How to determine the interrupt priority of CQ, PQ, FQ, and HPM in MSI mode？

ved-rivos commented 5 months ago

There is no priority specified. If all 4 of them are pending at same time then the IOMMU may send them one after the other in any order.