[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [PATCH v2 8/9] virtio-iommu: Add VIRTIO_IOMMU_RESV_MEM_T_IDENTITY
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]