From 6709369dff021cda018a5521fa9e62fb95fa77ae Mon Sep 17 00:00:00 2001 From: Ved Shanbhogue Date: Sat, 11 May 2024 18:07:31 -0500 Subject: [PATCH] formating updates --- iommu_data_structures.adoc | 2 ++ iommu_intro.adoc | 24 ++++++++++++++---------- 2 files changed, 16 insertions(+), 10 deletions(-) diff --git a/iommu_data_structures.adoc b/iommu_data_structures.adoc index 15679c21..64d32471 100644 --- a/iommu_data_structures.adoc +++ b/iommu_data_structures.adoc @@ -197,6 +197,8 @@ image::ddt-base.svg[width=800,height=400] //ddtp--->+--+ +->+--+ +->+--+ ddtp--->+--+ +->+--+ ddtp--->+--+ //.... +<<< + ==== Non-leaf DDT entry A valid (`V==1`) non-leaf DDT entry provides the PPN of the next level DDT. diff --git a/iommu_intro.adoc b/iommu_intro.adoc index 1b0e42a3..5218611b 100644 --- a/iommu_intro.adoc +++ b/iommu_intro.adoc @@ -55,6 +55,8 @@ 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. +<<< + The virtual memory scheme employed by the IOMMU may be configured individually per device in the IOMMU. Devices perform DMA using an I/O virtual address (IOVA). Depending on the virtual memory scheme selected for a device, the IOVA used by @@ -112,6 +114,8 @@ collection of processes that share a common virtual address space. The IOMMU may use the `GSCID` and `PSCID` to tag entries in the IOATC to avoid duplication and simplify invalidation operations. +<<< + Some devices may participate in the translation process and provide a device side ATC (DevATC) for its own memory accesses. By providing a DevATC, the device shares the translation caching responsibility and thereby reduce @@ -147,7 +151,7 @@ in the device context. === Glossary .Terms and definitions [width=90%] -[%header, cols="5,20"] +[%header, cols="5,25"] |=== | Term ^| Definition | AIA | RISC-V Advanced Interrupt Architecture cite:[AIA]. @@ -311,7 +315,7 @@ second-stage may be set to Bare. [[fig:device-isolation]] .Device isolation in non-virtualized OS -image::non-virt-OS.svg[width=300,height=300] +image::non-virt-OS.svg[width=300,height=300, align="center"] //["ditaa",shadows=false, separation=false, fontsize: 16] //.... @@ -356,7 +360,7 @@ and from D2 to VM-2 associated memory. [[fig:dma-translation-direct-device-assignment]] .DMA translation to enable direct device assignment -image::hypervisor.svg[width=300,height=300] +image::hypervisor.svg[width=300,height=300, align="center"] //["ditaa",shadows=false, separation=false, fontsize: 16] //.... //+----------------+ +----------------+ @@ -390,7 +394,7 @@ address, the same as supported by regular RISC-V page-based address translation. [[MSI_REDIR]] .MSI address translation to direct guest programmed MSI to IMSIC guest interrupt files -image::msi-imsic.svg[width=500,height=400] +image::msi-imsic.svg[width=500,height=400, align="center"] //["ditaa",shadows=false, separation=false, font=courier, fontsize: 16] //.... // +-----------------------+ @@ -450,7 +454,7 @@ protection function for device D3 and the second-stage is set to Bare. [[fig:iommu-for-guest-os]] .Address translation in IOMMU for Guest OS -image::guest-OS.svg[width=500,height=400] +image::guest-OS.svg[width=500,height=400, align="center"] //["ditaa",shadows=false, separation=false, fontsize: 16] //.... //+---------------------------------------------------+ @@ -515,7 +519,7 @@ The IOMMU is not invoked for outbound transactions. [[fig:example-soc-with-iommu]] .Example of IOMMUs integration in SoC. -image::placement.svg[width=800] +image::placement.svg[width=800, align="center"] The IOMMU is invoked by the IO Bridge for address translation and protection for inbound transactions. The data associated with the inbound transactions is not @@ -579,16 +583,16 @@ and has several interfaces (see <>): .. To receive "Page Request" and "Stop Marker" messages from the endpoints and to send "Page Request Group Response" messages to the endpoints. +[[fig:iommu-interfaces]] +.IOMMU interfaces. +image::interfaces.svg[width=800, align="center"] + The interfaces related to recording an incoming MSI in a memory-resident interrupt file (MRIF) (See RISC-V Advanced Interrupt Architecture cite:[AIA]) are implementation-specific. The partitioning of responsibility between the IOMMU and the IO bridge for recording the incoming MSI in an MRIF and generating the associated _notice_ MSI are implementation-specific. -[[fig:iommu-interfaces]] -.IOMMU interfaces. -image::interfaces.svg[width=800] - Similar to the RISC-V harts, physical memory attributes (PMA) and physical memory protection (PMP) checks must be completed on all inbound IO transactions even when the IOMMU is in bypass (`Bare` mode). The placement and integration of