formating updates

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.

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 <<fig:iommu-interfaces>>):
 .. 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