DMA 重映射

iommu 作用

安全性, 防止恶意访问
In the absence of an IOMMU, a device driver must program devices with Physical Addresses, which implies that DMA from a device could be used to access any memory, such as privileged memory,and cause malicious or unintended corruptions. This may be caused by hardware bugs, devicedriver bugs, or by malicious software/hardware. 013

在没有IOMMU的情况下，设备驱动程序必须用物理地址对设备进行编程，这意味着来自设备的DMA可以被用来访问任何内存，如特权内存，并造成恶意或意外的损坏。这可能是由硬件错误、设备驱动程序错误或恶意软件/硬件造成的。

使传统的32位外设可以访问超过4G的内存区间, 不再需要软件做 bounce buffers, 提高性能
Legacy 32-bit devices cannot access the memory above 4 GiB. 013
The integration of the IOMMU,through its address remapping capability, offers a simple mechanism for the DMA to directly accessany address in the system 013
Without an IOMMU, the OS must resort to copying data through buffers (also known as bounce buffers) allocated in memory below 4GiB. 013
The IOMMU can be useful as it permits to allocate large regions of memory without the need to becontiguous in physical memory 013
可以使用连续物理内存

中断重映射

MSI 重映射

To handle MSIs from a device controlled by a guest OS, the hypervisor configures an IOMMU toredirect those MSIs to a guest interrupt file in an IMSIC (see Figure 3) or to a memory-residentinterrupt file. The IOMMU is responsible to use the MSI address-translation data structures suppliedby the hypervisor to perform the MSI redirection. Because every interrupt file, real or virtual,occupies a naturally aligned 4-KiB page of address space, the required address translation is from avirtual (guest) page address to a physical page address, 015

hypervisor配置了一个IOMMU，将这些guest 的MSI (GPA) 重定向到IMSIC中的guest interrupt file (HPA)

利用 iommu 重定向能力使的 guest msi的GPA地址访问直接映射为 HPA的msi的地址访问, 从而让guest 可以直接读写物理msi mmio, 实现中断重映射能力, 中断直通给vcpu.

MSI 的地址重映射(GPA->HPA)是hypervisor 帮guest os做的 iommu 映射

Device-Directory-Table DDT

base format dc

extended format dc

Non-leaf DDT entry

A valid (V==1) non-leaf DDT entry provides PPN of the next level DDT.

Leaf DDT entry

The leaf DDT page is indexed by DDI[0] and holds the device-context (DC). 024
In base-format the DC is 32-bytes. In extended-format the DC is 64-bytes. 024

下面是base format dc DDI[0]的描述

Translation control (tc)

Translation control (tc) 025

The PDTV is expected to be set to 1 when DC is associated with a device that supports multiple process contexts and thus generates a valid process_id with its memory accesses. For PCIe, for example, if the request has a PASID then the PASID is used as the process_id. 027

tc.PDTV = 0 时, fsc 为 iostap/iovstap, 即1-stage 映射基址
tc.PDTV = 1 时, fsc 为 pdtp (associated with a device that supports multiple process contexts)

iohgatp

IO hypervisor guest address translation and protection (iohgatp) 027

The iohgatp field holds the PPN of the root G-stage page table and a virtual machine identified by aguest soft-context ID (GSCID) 027

The root page table as determined by iohgatp.PPN is 16 KiB and must be aligned to a 16-KiBboundary. If the root page table is not aligned to 16 KiB as required, then all entries in that G-stageroot page table appear to an IOMMU as UNSPECIFIED and any address an IOMMU may compute anduse for accessing an entry in the root page table is also UNSPECIFIED. 027

iohgatp.mode

The G-stage page table format and MODE encoding follow the format defined by the privileged specification. 027
mode-> Bare or 同hgatp的mode

fsc

First-Stage context (fsc) 027

tc.PDTV = 0 & iohgatp.mode = Bare 该域表示 iosatp;
tc.PDTV = 0 & iohgatp.mode != Bare 该域表示 iovstatp

格式同satp

tc.PDTV = 1 该域表示 PDTP

When PDTV is 1, the fsc field holds the process-directory table pointer (pdtp). 028

When the device supports multiple process contexts, selected by the process_id, the PDT is used to determine the S/VS-stage page table and associated PSCID for virtual address translation and protection. 028

The pdtp field holds the PPN of the root PDT and the MODE field that determines the number of levels of the PDT.

PDT 和 PSCID 结合找出对应的页表基址

pdtp.mode

^a5d0fe

ta

Translation attributes (ta) 028

The PSCID field of ta provides the process soft-context ID that identifies the address-space of the process. PSCID facilitates address-translation fences on a per-address-space basis.
The PSCID field in ta is used as the address-space ID if PDTV is 0 and the iosatp/iovsatp MODE field is not Bare. 029

tc.pdtv = 0 & iosatp/iovsatp.mode != Bare 时, ta.PSCID 表示ASID

PDT Process-Directory-Table

Non-leaf PDT entry

V == 1 表示为非leaf 节点

Leaf PDT entry

First-Stage context (fsc)

First-Stage context (fsc) 031

The software assigned process soft-context ID (PSCID) is used as the address space ID (ASID) for the process identified by the S/VS-stage page table. 032

pdtv = 1
The pdtp field holds the PPN of the root PDT and the MODE field that determines the number of levels of the PDT.

pdtp.mode 确定了使用几级页表

Translation attributes (ta)

PC is valid if the V bit is 1; If it is 0, all other bits in PC are don’t care and may be freely used bysoftware. 031

MSI page table

MSI page table pointer (msiptp) 029
DC.msiptp

An MSI page table is a flat array of MSI page table entries (MSI PTEs) 032
Msi page table 只有一级页表

地址A匹配

a write to guest physical address A is recognized as an MSI to a virtual interrupt file 029
(A >> 12) & ~msi_addr_mask = (msi_addr_pattern & ~msi_addr_mask)
认为是msi 地址

Each MSI PTE may specify either the address of a real guest interruptfile that substitutes for the targeted virtual interrupt file (下图1), or a memory-residentinterrupt file in which to store incoming MSIs for the virtual interrupt file(下图2) . 032

MSI PTE write-through mode

also called msipte

If V = 1 and the custom-use bit C = 0, then bit 2 of the first doubleword is field W (Write-through). If W = 1, the MSI PTE specifies write-through mode for incoming MSIs, and if W = 0, it specifies MRIFmode. 033

When an MSI PTE has fields V = 1, C = 0, and W = 1 (write-through mode), the PTE’s complete
format is:

An MSI PTE in write-through mode allows a hypervisor to route an MSI intended for a virtual interrupt file to go instead to a guest interrupt file of a real IMSIC in the machine. 033

Memory-Mapped Register

所有的寄存器在下面的这个表格中
Table 10. IOMMU Memory-mapped register layout 065

其中比较重要的有ddtp

ddtp

Device-directory-table pointer (ddtp) 069

iommu_mode

IOMMU capabilities

IOMMU capabilities (capabilities) 066

翻译过程

Process to translate an IOVA

Process to translate an IOVA 038

整个翻译过程还是比较复杂的, 需要根据多个字段判断是DC/PC/MSI table
最终将pte确定后, 根据iohgatp.mode 确定是2-stage 还是1-stage 的SPA/GPA翻译.

用device_id 来确定DDT的叶子节点DDTE 是必须的, 无论最终是 locate DC/PC/MSI, 都需要DDTE的解读.

Process to translate addresses of MSIs

Process to translate addresses of MSIs 043

省略了MRIF 模式, 这部分比较复杂, 一般也用不到, 等用到的时候再另行分析

非MRIF模式, 即msipte.W=1时, 提取的IMSIC的interrupt file 的index no为 extract(iova>>12, DC.msi_addr_mask)
◦ x = a b c d e f g h
◦ y = 1 0 1 0 0 1 1 0
◦ r = acfg

最终配置的地址为 msipte.PPN << 12 | iova[11:0], 其中 msipte = DC.msiptp.PPN << 12 | interrupt_file_no * 16;

Process to locate the Device-context

Process to locate the Device-context 040
use device_id, 该流程是和前面的 translate iova 结合来看的

The device context is located using the hardware provided unique device_id. The supported device_id width may be up to 24-bit. 019

capabilities.MSI_FLAT == 0

DDI[0] -> device_id[6:0]
DDI[1] -> device_id[15:7]
DDI[2] -> device_id[23:16]
capabilities.MSI_FLAT == 1

DDI[0] -> device_id[5:0]
DDI[1] -> device_id[14:6]
DDI[2] -> device_id[23:15]

如capabilities.MSI_FLAT == 0 时, base dc walk 图

Process to locate the Process-context

Process to locate the Process-context 042
use process_id
The hardware identities associated with transaction - the device_id and if applicable the process_id. The IOMMU uses the hardware identities to retrieve the context information to perform the requested address translations 017

process_id 是20 bit, 由pdtp.MODE 确定几级页表

PDI[0] = process_id[7:0]
PDI[1] = process_id[16:8]
PDI[2] = process_id[19:17]

Queue Interface

A command-queue (CQ) used by software to queue commands to the IOMMU.
A fault/event queue (FQ) used by IOMMU to bring faults and events to software attention.
A page-request queue (PQ) used by IOMMU to report “Page Request” messages received from
PCIe devices. This queue is supported if the IOMMU supports PCIe defined Page Request
Interface

CQ

cmdq

The PPN of the base of this in-memory queue and the size of the queue is configured into a
memory-mapped register called command-queue base (cqb).

The tail of the command-queue resides in a software controlled read/write memory-mapped
register called command-queue tail (cqt).

The head of the command-queue resides in a read-only memory-mapped IOMMU controlled
register called command-queue head (cqh)

If cqh == cqt, the command-queue is empty.
If cqt == (cqh - 1) the command-queue is full.

IOMMU Page-Table cache invalidation commands

IOTINVAL.VMA ensures that previous stores made to the S/VS-stage page tables by the harts are
observed by the IOMMU before all subsequent implicit reads from IOMMU to the corresponding
S/VS-stage page tables.

IOTINVAL.GVMA ensures that previous stores made to the G-stage page tables are observed before all
subsequent implicit reads from IOMMU to the corresponding G-stage page tables. Setting PSCV to 1
with IOTINVAL.GVMA is illegal.

IOMMU Command-queue Fence commands

A IOFENCE.C command guarantees that all previous commands fetched from the CQ have been
completed and committed

FQ

faultq

Fault/Event queue is an in-memory queue data structure used to report events and faults raised
when processing transactions.

The PPN of the base of this in-memory queue and the size of the queue is configured into a
memory-mapped register called fault-queue base (fqb).

The tail of the fault-queue resides in a IOMMU controlled read-only memory-mapped register called
fqt.

The fqh is an index into the next fault record that SW should process next.

CAUSE:

PQ

priq or Page-Request-Queue

Page-request queue is an in-memory queue data structure used to report PCIe ATS “Page Request”
and “Stop Marker” messages to software.

The base PPN of this in-memory queue and the size of the queue is configured into a memory-mapped register called page-request queue base (pqb).

The tail of the queue resides in a IOMMU controlled read-only memory-mapped register called pqt.

The head of the queue resides in a software controlled read/write memory-mapped register called
pqh.

If pqh == pqt, the page-request queue is empty.
If pqt == (pqh - 1) the page-request queue is full.

PCIe 相关

ATS & PRI
Address Translate Service
Page Request Interface

PCIe 设备可以发出缺页请求，iommu硬件在解析到缺页请求后可以直接将缺页请求写入 PRI queue (PQ), 软件在建立好页表后，可以通过CMD queue 发送 PRI response 给 PCIe 设备。具体的 ATS 和 PRI 的实现是硬件相关的
软件控制 DMA 发起后，设备先发起 ATC 请求，从 IOMMU 请求该 va 对应的 pa，如果 IOMMU 里已经有 va 到 pa 的映射，那么设备可以得到 pa，然后设备再用 pa 发起一次内存访问，该访问将直接访问对应 pa 地址，不在 IOMMU 做地址翻译;
如果 IOMMU 没有 va 到 pa 的映射, 那么设备得到这个消息后会继续向 IOMMU 发 PRI 请求，设备得到从 IOMMU 来的 PRI response 后发送内存访问请求，该请求就可以在 IOMMU 中翻译得到 pa, 最终访问到物理内存。

从上述链路的角度看, 设备端相当于做了tlb的事情.

ATS机制想要解决的问题（优势)：

能够分担主机（CPU）侧的查表压力，特别是大带宽、大拓扑下的IO数据流，CPU侧的IOMMU的查表将会成为性能瓶颈，而ATS机制正好可以提供将这些查表压力卸载到不同的设备中，对整个系统实现“who consume it， who pay for it”。
决定查表性能的好坏的一个最为关键的点是TLB的预测。而像传统PCIe IO数据流，在CPU侧集中式做IOMMU的查表，对于其TLB的预测（prefetch）是很困难，极为不友好的。因为很多不同workload的IO流汇聚到一点，对于TLB的预测的冲击很大，流之间的干扰很大，很难做出准确的预测，从而TLB的命中率始终做不到太高，从而影响IO性能。而ATS的机制恰好提供了一个TLB的预测卸载到源头去的机制，让用户（设备）自己根据自己自身的业务流来设计自己的预测策略，而且用户彼此之间的预测模型不会受到彼此的影响，从而大大提高了用户自己的预测的准确性。抽象来看，这时候的设备更像是CPU核，直接根据自身跑的workload来预测本地的TLB，从而提升预测性能，进而提升整系统的预测性能。

blog

riscv iommu SPEC 调研