[PATCH v2 8/9] virtio-iommu: Add VIRTIO_IOMMU_RESV_MEM_T_IDENTITY

[Jean-Philippe Brucker <jean-philippe@linaro.org>]

To support MSIs on platforms that translate MSI addresses (Arm, possibly
RISC-V), when using page tables, the driver needs to create IOVA-GPA
mappings of addresses reserved by the platform.

Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
 device-types/iommu/description.tex | 30 +++++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/device-types/iommu/description.tex b/device-types/iommu/description.tex
index 38f94f8..dcb51d3 100644
--- a/device-types/iommu/description.tex
+++ b/device-types/iommu/description.tex
@@ -1031,7 +1031,10 @@ \subsubsection{PROBE properties}\label{sec:Device Types / IOMMU Device / Device
   u8    reserved[3];
   le64  start;
   le64  end;
+  le32  flags;
 };
+
+#define VIRTIO_IOMMU_RESV_MEM_F_MMIO      (1 << 0)
 \end{lstlisting}
 
 Fields \field{start} and \field{end} describe the range of reserved virtual
@@ -1051,6 +1054,27 @@ \subsubsection{PROBE properties}\label{sec:Device Types / IOMMU Device / Device
     In addition it provides information about MSI doorbells. If the
     endpoint doesn't have a VIRTIO_IOMMU_RESV_MEM_T_MSI property, then the
     driver creates an MMIO mapping to the doorbell of the MSI controller.
+
+  \item[VIRTIO_IOMMU_RESV_MEM_T_IDENTITY (2)]
+    When using page tables, the driver creates an identity
+    mapping for this region, in order to get full functionality
+    of the endpoint. When not using page tables, this behaves
+    like a VIRTIO_IOMMU_RESV_MEM_T_RESERVED region.
+
+    The intent is to create MSI doorbell mappings when the driver
+    uses VIRTIO_IOMMU_T_ATTACH_TABLE, the platform manages MSIs
+    and the hardware IOMMU translates MSI addresses using page
+    tables. In that case the driver fully controls the mappings,
+    so the platform requests through this property that the
+    driver creates itself the mapping to the MSI doorbell. When
+    not using page tables, the platform can create the mappings
+    itself and this is simply a reserved region.
+
+    Flag VIRTIO_IOMMU_RESV_MEM_F_MMIO tells the driver to create
+    an MMIO mapping.
+    \todo{Does each acceleration need to define what MMIO means?
+    Arm has a lot of MMIO flavors. Do we need a common
+    non-cacheable definition as well?}
 \end{description}
 
 \drivernormative{\subparagraph}{Property RESV_MEM}{Device Types / IOMMU Device / Device operations / PROBE properties / RESVMEM}
@@ -1063,6 +1087,9 @@ \subsubsection{PROBE properties}\label{sec:Device Types / IOMMU Device / Device
 The driver SHOULD treat any \field{subtype} it doesn't recognize as if it
 was VIRTIO_IOMMU_RESV_MEM_T_RESERVED.
 
+The driver SHOULD create an identity mapping described by
+VIRTIO_IOMMU_RESV_MEM_T_IDENTITY, when using page tables.
+
 \devicenormative{\subparagraph}{Property RESV_MEM}{Device Types / IOMMU Device / Device operations / PROBE properties / RESVMEM}
 
 The device SHOULD set \field{reserved} to zero.
@@ -1073,7 +1100,8 @@ \subsubsection{PROBE properties}\label{sec:Device Types / IOMMU Device / Device
 The device SHOULD NOT present multiple RESV_MEM properties that overlap
 each other for the same endpoint.
 
-The device SHOULD reject a MAP request that overlaps a RESV_MEM region.
+The device SHOULD reject a MAP request that overlaps a RESV_MEM
+region.
 
 The device SHOULD NOT allow accesses from the endpoint to RESV_MEM regions
 to affect any other component than the endpoint and the driver.
-- 
2.42.0