formating updates

Author: ved-rivos

iommu_intro.adoc

@@ -293,26 +293,6 @@ in <<fig:device-isolation>> the OS may configure the IOMMU with a page table to
 translate the IOVA and thereby limit the addresses that may be accessed to those
 allowed by the page table.
 
-Legacy 32-bit devices cannot access the memory above 4 GiB. The IOMMU, through
-its address remapping capability, offers a simple mechanism for the device to
-directly access any address in the system (with appropriate access permission).
-Without an IOMMU, the OS must resort to copying data through buffers (also
-known as bounce buffers) allocated in memory below 4 GiB. In this scenario the
-IOMMU improves the system performance.
-
-The IOMMU can be useful to perform scatter/gather DMA as it permits to allocate
-large regions of memory for I/O without the need for all of the memory to be
-contiguous. A contiguous virtual address range can map to such fragmented
-physical addresses and the device programmed with the virtual address range.
-
-The IOMMU can be used to support shared virtual addressing which is the ability
-to share a process address space with devices. The virtual addresses used for
-DMA are then translated by the IOMMU to an SPA.
-
-When the IOMMU is used by a non-virtualized OS, the first-stage suffices to
-provide the required address translation and protection function and the
-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, align="center"]
@@ -340,6 +320,26 @@ image::non-virt-OS.svg[width=300,height=300, align="center"]
 //   +--------+
 //....
 
+Legacy 32-bit devices cannot access the memory above 4 GiB. The IOMMU, through
+its address remapping capability, offers a simple mechanism for the device to
+directly access any address in the system (with appropriate access permission).
+Without an IOMMU, the OS must resort to copying data through buffers (also
+known as bounce buffers) allocated in memory below 4 GiB. In this scenario the
+IOMMU improves the system performance.
+
+The IOMMU can be useful to perform scatter/gather DMA as it permits to allocate
+large regions of memory for I/O without the need for all of the memory to be
+contiguous. A contiguous virtual address range can map to such fragmented
+physical addresses and the device programmed with the virtual address range.
+
+The IOMMU can be used to support shared virtual addressing which is the ability
+to share a process address space with devices. The virtual addresses used for
+DMA are then translated by the IOMMU to an SPA.
+
+When the IOMMU is used by a non-virtualized OS, the first-stage suffices to
+provide the required address translation and protection function and the
+second-stage may be set to Bare.
+
 ==== Hypervisor
 
 IOMMU makes it possible for a guest operating system, running in a virtual
@@ -440,18 +440,6 @@ hypervisor.
 
 <<fig:iommu-for-guest-os>> illustrates the concept. 
 
-The IOMMU is configured to perform address translation using a first-stage
-and second-stage page table for device D1. The second-stage is typically used by
-the hypervisor to translate GPA to SPA and limit the device D1 to memory
-associated with VM-1. The first-stage is typically configured by the Guest OS to
-translate a VA to a GPA and contain device D1 access to a subset of VM-1 memory.
-
-For device D2 only the second-stage is active and the first-stage is set to Bare.
-
-The host OS or hypervisor may also retain a device, such as D3, for its own use.
-The first-stage suffices to provide the required address translation and
-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, align="center"]
@@ -484,6 +472,18 @@ image::guest-OS.svg[width=500,height=400, align="center"]
 //  +-----------+     +-----------+     +-----------+
 //....
 
+The IOMMU is configured to perform address translation using a first-stage
+and second-stage page table for device D1. The second-stage is typically used by
+the hypervisor to translate GPA to SPA and limit the device D1 to memory
+associated with VM-1. The first-stage is typically configured by the Guest OS to
+translate a VA to a GPA and contain device D1 access to a subset of VM-1 memory.
+
+For device D2 only the second-stage is active and the first-stage is set to Bare.
+
+The host OS or hypervisor may also retain a device, such as D3, for its own use.
+The first-stage suffices to provide the required address translation and
+protection function for device D3 and the second-stage is set to Bare.
+
 === Placement and data flow
 
 <<fig:example-soc-with-iommu>> shows an example of a typical system on a chip
@@ -643,6 +643,8 @@ Other implementation-specific methods in the IO bridge may be provided to
 perform such authentication.
 ====
 
+<<<
+
 === IOMMU features
 Version 1.0 of the RISC-V IOMMU specification supports the following
 features: