search

riscv-non-isa / riscv-iommu

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

Can A in the first step of MSI translation process be directly IOVA? #238

Closed 18772820305 closed 1 year ago

18772820305 commented 1 year ago

Step 1 in the process to translate addresses of MSI in section 2.3.3 let A be the GPA, is the GPA mentioned in it directly from IOVA?

ved-rivos commented 1 year ago

The process in section 2.3.3 is invoked by the step 18 of the process in section 2.3 and the GPA may be directly from the IOVA or could be the result of the translation using the first stage address translation process.

18772820305 commented 1 year ago

After querying the DC to get msi_addr_mask and msi_addr_pattern, can i directly judge whether the virtual interrupt file is accessed by IOVA through the formula provided in Section 2.1.3.6?

ved-rivos commented 1 year ago

Section 2.3 outlines the process to translate an IOVA. In step 6, the device_id is used to locate the DC. At this step whether the IOVA is a GPA is not known. Subsequently the step 17 determines the GPA. Only after step 17 i.e. after a GPA has been determined, the step 18 - MSI address translation process - is invoked. In MSI address translation process, the msi_addr_mask and msi_addr_pattern from the DC determined in step 6 is used - in step 3 - to determine if GPA is that of a virtual interrupt file using the algorithm specified in section 2.1.3.6.

18772820305 commented 1 year ago

Does the address sent by the device for writing to the virtual interrupt file must be a GPA? If it is GPA, can it directly recognize that IOVA is writing virtual interrupt files after obtaining DC.

ved-rivos commented 1 year ago

The process is then the section 2.3 is the only defined process. A compliant implementation must adhere to this process.

The address provided by a device is an IOVA. The RISC-V IOMMU employs a two-stage address translation process to translate the IOVA to an SPA. Although there is no option to disable two-stage address translation, either stage may be effectively disabled by configuring the virtual memory scheme for that stage to be Bare i.e. perform no address translation or memory protection.

So the process following is always:

  1. Locate device context - this provides the second-stage address translation controls. The second stage may be Bare
  2. If process_id is valid locate the process context - this provides the first-stage address translation controls. The first stage may be Bare
  3. Translate IOVA to a GPA using the first stage - there may not be a translation needed if first stage is Bare
  4. Use this GPA to do MSI address translation if it is address of a virtual interrupt file
  5. If it is not address of virtual interrupt file translate the GPA to SPA using the second stage - there may not be a translation needed if second stage is Bare

If your questions are about whether in your implementation you can take certain shortcuts or deviate from this process then I can help you if you would more clearly state what you are attempting to do and what your assumptions are.

ved-rivos commented 1 year ago

Please re-open if there are further items to discuss.