PCIe Chapter 27：ATS、PRI 與 PASID 的位址轉譯流程

想追一筆 DMA，先把哪些角色放到圖上？

DMA

Direct Memory Access，裝置直接存取記憶體

先開 Figure 10-1 Example Illustrating a Platform with TA, ATPT, and ATC Elements。裝置的 ATC 保存轉譯結果；平台的 TA 依 ATPT（Address Translation and Protection Table，位址轉譯與保護資料表）判斷映射與權限。TA 與資料表可以分開或整合，具體實作由平台決定。再用 Figure 10-2 追 Request 與 Translation Completion，才開始看實際 DMA（Direct Memory Access，裝置直接記憶體存取）。

【模擬資料】以下資料為教學用途建立，不代表特定硬體或平台。本章使用單一 Endpoint Function，Requester ID=0300h，PASID=00021h，處於 D0、Bus Master Enable=1。平台已允許這個身分使用相應服務，路徑可傳遞本例封包；TC0／TC1 的必要傳輸已就緒。正常算例採 Non-Flit Mode，沒有 Reset、Replay 或 PASID 停用／重用事件。

PASID

Process Address Space ID，程序位址空間識別碼

本章直接依 Base 6.0 Chapter 10 與 §6.20；平台頁表格式、特定 IOMMU（Input/Output Memory Management Unit，I/O 記憶體管理單元）暫存器及作業系統介面另須查實際文件。Switch 可透明轉送 ATS 封包，不必因此成為 TA，或各自具有 ATS Requester Capability。

Base 6.0 §10.1.1，Figures 10-1／10-2，pp.1470–1474；本章的身分、設定、映射及 Trace 均為作者建立。

同樣 PASID=21h，就一定是同一個程序嗎？

先依 §6.20 把 PASID 與 Requester ID 配對。各 Function 有自己的 PASID 集合；另一個 RID=0310h 使用 21h，並不由此得到與 0300h 相同的位址空間。PASID 也不是作業系統 PID 的通用編碼，Function 如何將它連到工作上下文，由裝置與平台處理。

RID

Routing ID，封包使用的路由識別碼

Non-Flit Mode 的 PASID 位於 End-End TLP Prefix，依 Figure 6-20／Table 6-15 解碼。本例 Execute Requested=0、Privileged Mode Requested=0，PASID=00021h，四個位元組為 91 00 00 21。Flit Mode 改放在 OHC-A1（承載 PASID 等資訊的標頭區塊）；Translation Request 的 No Write 也須改讀這個區塊，不能把 Non-Flit 的欄位位置直接套過去。

TLP

Transaction Layer Packet，交易層封包

Max PASID Width=8 允許 0–255，21h 在範圍內；PASID=0 也是可用值，不能自行當成保留編碼。一般 Completion 不允許帶 PASID，Translation Completion 也一樣；收到它時，裝置須依 Requester ID／Tag 找回原 Translation Request 保存的 PASID 上下文。後文的 PRG（Page Request Group，頁面要求群組）Response 則是規格另外允許帶 PASID 的 Message。

如果 Function 已啟用 Translated Requests with PASID，且這筆映射是用 PASID=21h 查得，後續使用該映射的 Translated Request 須帶同一個 PASID；Execute Requested 與 Privileged Mode Requested 也須分別符合轉譯回覆的 Exe、Priv。若原本查詢沒有 PASID，對應的 Translated Request 也不得帶 PASID。這些條件與稍後解讀權限的流程相連。

Base 6.0 §§6.20–6.20.2.2，Figure 6-20 PASID TLP Prefix、Table 6-15，pp.791–793；§10.1.3 Process Address Space ID (PASID)，pp.1477–1478。

能力、啟用與目前需求，該分別查哪張圖？

先找三個不同結構：PASID ID=001Bh、ATS ID=000Fh、Page Request ID=0013h，本版的 Version 均為 1。起點分別記為 P、A、R。Figures 7-185、10-29、10-33 定位結構，再用各自的 Register Table 解碼：

PASID Capability 的 0808h 表示 8-bit 寬度、支援 Translated Requests with PASID；本例不要求 Execute／Privileged Mode。Control=0009h 同時啟用 PASID 與帶 PASID 的 Translated Requests。必須在 ATS Enable=0 時先設好 PASID Control，再將 ATS Control 設為 8000h；ATS Enable 已為一時改任何 PASID Control bit，行為為 undefined。

ATS 的 STU（Smallest Translation Unit，最小轉譯單位）=0，表示 2⁰×4 KiB＝4 KiB；它不是關閉轉譯。Invalidate Queue Depth=4 是失效要求的資源資訊，不是 Page Request 額度。ATS Memory Attributes 在本例未啟用，不自行解讀其平台特定值。

在 Page Request Enable=0 時，將 Allocation 設為 3，低於 Capacity=4；確認 Stopped=1 後才啟用。在啟用中更改 Allocation，行為為 undefined（規格未定義）；尚未成功停止就重新啟用，結果則為 indeterminate（無法確定）。Stopped 只在 Enable=0 時有意義；啟用後不能靠它的零或一判斷「目前沒有 Page Request」。

ATS 不必搭配 PRI；PASID 也不是只有 ATS／PRI 才能使用。Root Complex 的 PASID 支援與啟用機制由平台定義，不能在 Root Port 內尋找與 Endpoint 相同的 PASID Control。

Base 6.0 §7.8.9，Figures 7-185–7-188、Tables 7-159–7-161，pp.1148–1151；§10.5.1，Figures 10-29–10-32、Tables 10-9–10-11，pp.1513–1516；§10.5.2，Figures 10-33–10-36、Tables 10-13–10-15，pp.1516–1520。

ATS 的能力與控制欄位，如何影響前面的案例？

先沿 Extended Capability 清單找到 ATS：Figure 10-30／Table 10-9 的 ID 是 000Fh、Version 是 1，Next Capability Offset 以 Configuration Space 起點為基準。把本次找到的結構起點記為 A；Figure 10-29 接著指出 A+04h 是 16-bit ATS Capability，A+06h 是 16-bit ATS Control。

沿用前面的作者假設：非 VF Function 讀到 Capability=0024h、Control=8000h。從 Figure 10-31／Table 10-10 看，Queue Depth=4、Page Aligned Request=1，而 Global Invalidate Supported、Relaxed Ordering Supported、ATS Memory Attributes Supported 都為 0。這是此 Function 的能力快照，不代表其他 Function 也相同。

VF

Virtual Function，虛擬功能

手機閱讀時，可左右滑動表格查看完整內容。

再看 Figure 10-32／Table 10-11：本例 E=1、STU=0，表示允許快取轉譯，且最小轉譯單位為 4 KiB。若另設教學值 STU=2，單位是 2² × 4 KiB = 16 KiB；欄位描述轉譯與失效範圍的最小單位，不是 Translation Request 的完整長度。

AMAE 控制 Requester 是否可在 TPH TLP Prefix 提供 AMA；AMAD 在 AMAE 設置時提供預設 AMA 及相應最佳化。本例 AMAE=0，不能把 AMAD 當成已啟用的傳輸行為。 Table 10-11 對 STU、AMAD、AMAE 與 E 的預設值均列為 0。若 Endpoint 支援 PASID，在 ATS 的 E=1 期間改變任何 PASID Control bit，行為未定義。

TPH

TLP Processing Hints，封包處理提示

TLP

Transaction Layer Packet，交易層封包

對 SR-IOV，VF 的 ATS Capability 可與 PF 分別啟用；但 VF 的 Invalidate Queue Depth 與 STU 欄位硬接為零，使用相關 PF 的值。不能只憑 VF 讀到零，認為其失效佇列不可用或 STU 必定是 4 KiB。Base 6.0 §10.5.1–§10.5.1.3、Figures 10-29–10-32、Tables 10-9–10-11，文件／PDF pp.1513–1516。 Device Control 的 Enable Relaxed Ordering 見 Table 7-21，p.960。

SR-IOV

Single Root I/O Virtualization，單根I/O虛擬化

VF

Virtual Function，虛擬功能

PF

Physical Function，實體功能

要讀 40001234h 的四個位元組，先查什麼？

先依 Table 10-1 分辨 AT（Address Type，位址類型）：00b 是 Untranslated，01b 是 Translation Request，10b 是 Translated。00b 的位址由 TA 決定如何處理，不代表所有平台都把它直接當成 CPU 虛擬位址；10b 也不代表平台跳過權限檢查。

案例要讀未轉譯位址 40001234h。因 Page Aligned Request=1，先對齊到 40001000h，再按 Figures 10-10／10-11 形成 AT=01b 的 MRd（Memory Read，讀取要求）。TA 再以 CplD（Completion with Data，帶資料的完成封包）回覆轉譯結果。Length=2 DW 表示最多回一筆 8-byte 轉譯項目，並非向應用程式讀八個位元組。NW（No Write，不要求寫入）=1，本例只需要讀取。

DW

Double Word，4 bytes的資料單位

Translation Completion 依 Figure 10-14 Translation Completion Data Entry 與 Table 10-3 解碼：本例 S=0 表示 4 KiB，R=1、W=0、U=0 允許以這個轉譯位址做非零長度讀取；Global、Priv、Exe、N、AMA 均假設為零。未轉譯頁內 offset=234h，故實際位址為 90000000h＋234h＝90000234h。對應範圍是 90000000h–90000FFFh，四個位元組 沒有跨頁。

後面 Tag=2Bh 的 Memory Read 是另一筆 Transaction。本例 Trace 最後觀察到 SC（Successful Completion，成功完成狀態）與四個位元組的應用資料，才確認這筆讀取的結果。前一筆 Tag=2Ah 的 SC 只配對轉譯查詢。Translation Request 也不能拿來當成其他 Write 已完成的排序屏障。

Base 6.0 §§10.2.1–10.2.2，Table 10-1、Figures 10-6–10-13，pp.1478–1483；§10.2.3，Figure 10-14／Table 10-3，pp.1484–1489；§10.2.4，p.1496。兩種模式的基本 Header 另見 Chapter 14。

想一次查兩頁，Translation Request 的 Length 怎麼讀？

接續前面的模擬案例，假設 STU=0、Page Aligned Request=1，從 40001000h 開始要求兩個連續的 4 KiB 轉譯區間。Length 設為 4 DW，代表最多返回兩筆轉譯項目：每筆項目是 8 bytes，對應一個或多個 STU。這裡的 Length 描述可能返回的轉譯資訊，不是要讀取的應用資料大小。TA 可以返回較少項目，不能返回超過要求的項目；收到第一筆後，仍要依其範圍與權限確認實際可使用的映射。

依 §10.2.2.2 和 §10.2.2.4，本例隱含的查詢範圍為 2⁰⁺¹² × (4÷2)＝8 KiB。Length 必須是偶數個 DW，且不超過 Root Port 的 Read Completion Boundary（RCB，讀取完成邊界）所允許的上限；若設定超過上限或 DW 數為奇數，TA 依規格將要求視為 Malformed Packet（格式錯誤的封包）。

再回頭核對 Figures 10-10–10-13：Non-Flit Mode 的 NW 位於 Request Header；Flit Mode 必須包含 OHC-A1，NW 位於 OHC-A1。NW=1 表示只要求讀取權限，但 TA 可以忽略此提示；最後仍須以 Translation Completion 的 R/W 等欄位判斷。NW=0 在 Flit Mode 下還受明確寫入權限的要求限制，不能只憑 NW 位元認定裝置已獲授權。

若 Request 帶 PASID，未轉譯位址屬於該 PASID 指定的程序位址空間。Tag 與 Memory Read 的 Tag 有相同用途；收到轉譯回覆後，仍要把它和對應 Request 配對。這筆 Translation Request 本身也不能當成其他交易的排序屏障。

Base 6.0 §§10.2.2.1–10.2.2.6，Figures 10-10–10-13，pp.1481–1483；位址類型另見 §10.2.1、Table 10-1，pp.1478–1480。

兩筆轉譯分成兩個 Completion，如何知道還有下一筆？

接續要求兩筆轉譯的模擬案例。TA 可以只返回其中一筆，也可以返回兩筆；返回多筆時，項目的轉譯範圍須等大、在未轉譯位址空間中相鄰。成功的 Translation Completion 可以由一個或兩個 CplD 組成，每個 CplD 都要包含完整的轉譯項目。

【模擬資料】假設 TA 決定返回兩筆，每筆 8 bytes，分別放進兩個 CplD；Root Port 的 RCB 是 64 bytes。兩個 CplD 的 Requester ID 和 Tag 都對應原本的 Translation Request。

再依 §10.2.3 與 Figures 10-15、10-16 讀 Lower Address：本例第一個是 64−16＝48（30h），第二個是 0。這是為了符合 RCB 語意而計算的值，不能拿它當成原始未轉譯位址的低位元。每筆轉譯的範圍和權限仍要回到 Figure 10-14 解碼。

如果 TA 只返回一筆，不能單憑數量較少就判定錯誤。另一方面，R=W=0 的項目仍表示一段範圍中的空缺，TA 不可為了補齊截短的結果而加入這種項目。分析時先分清楚是實際回傳的無權限區間，還是後續區間根本沒有返回。

Base 6.0 §10.2.3、Figures 10-14–10-16，pp.1485–1493；§10.2.4 Completions with Multiple Translations，p.1496。

轉譯項目不是 4 KiB 時，怎麼找出範圍？

前面的模擬資料使用 S=0，對應 4 KiB。若 S=1，先讀 Figure 10-14 找到 S 與 Translated Address，再讀 Table 10-5：從 address bit 12 開始，連續的 1 和接著遇到的 0 一起決定範圍大小；這些低位元在解碼時表示大小，不能直接當成一般位址位元。

【模擬資料】假設 S=1，回覆中 Translated Address 為 90001000h，其 bit 12=1、bit 13=0。依 Table 10-5 得到 16 KiB；去掉用來表示大小的低位元後，範圍是 90000000h–90003FFFh。這個例子假設 R=1、W=0、U=0，其讀取權限還須與 Request 的身分及其他條件一起核對。

S 的編碼單位固定以 4 KiB 為基礎，STU 則是 Function 設定的最小轉譯單位。若 STU=2，最小單位為 16 KiB，本例的範圍符合該大小；如果 STU=3，最小單位是 32 KiB，收到這筆 16 KiB 的 Translation Completion 時，Function 必須按 UR（Unsupported Request，不支援要求）處理。

同一筆項目的 N（Non-snooped）也要讀：N=1 時，使用此轉譯的 Memory Read／Write 必須清除 Request 的 No Snoop；N=0 不代表一定要設 No Snoop，還要看 Function 和 Device Control 的 Enable No Snoop。U=1 時，N 的意義為 undefined，不能拿它判斷後續 Request 的屬性。

Base 6.0 §10.2.3，Figure 10-14、Table 10-3，pp.1485–1486；§§10.2.3.1–10.2.3.3、Table 10-5，pp.1487–1488。

收到 SC，為何仍可能不能發 Translated Read？

R=W=0 時，S 與範圍資訊仍用來描述該區段；地址及其他指定欄位則為 undefined。平台日後可能把無效映射變成有效，卻不必因此送失效通知，所以 ATC 不得保存這筆「沒有權限」的結果當成持久的負向快取。

U（Untranslated access only，只允許未轉譯存取）=1 時，可快取規格允許的權限／範圍資訊，但不得把回覆地址放進 AT=10b 的 Request。若 R=1、W=0，之後需要寫入，也應另取新轉譯與相應授權，不能自行改 ATC 的 W bit。

另外，Table 10-2 的 UR（Unsupported Request，不支援要求）與 CA（Completer Abort，完成端中止）是沒有 Data 的失敗回覆。收到 UR 後，Function 必須停用 ATC，在重新啟用前不得再使用轉譯位址；CA 則表示 TA 因內部錯誤無法完成轉譯。RRS（要求重試狀態）不允許用於 Translation Request，收到時按 Malformed TLP 處理。上一章 Configuration Request 可暫時回 RRS 的條件，不能搬到這裡。以上結果也不足以單獨診斷頁面未駐留、權限被拒或平台哪個元件故障。

Base 6.0 §10.2.3，Table 10-2 Translation Completion with No Data Status Codes，p.1484；§§10.2.3.1–10.2.3.5，pp.1487–1489。

映射改變後，收到第一筆失效回覆就結束嗎？

接續案例，平台要改變 PASID=21h、40001000h–40001FFFh 的映射。先依模式看 Figures 10-18／10-19 的 Invalidate Request，再看 Figure 10-20 的未轉譯範圍與 Global Invalidate。假設這次 ITag=3、TC0、只針對本 PASID，範圍 4 KiB，沒有 Global Mapping。

裝置須讓新 Request 不再使用舊轉譯；相關 Outstanding Reads 必須完成或標記丟棄，相關 Posted Writes 則須推送到 TA，不能只刪 ATC entry 就回完成。若 Invalidate Request 與尚未回來的 Translation Completion 範圍重疊，還須依 §10.3.6 處理舊查詢結果，避免失效後又把舊映射放回 ATC。

為了追蹤跨 TC 的推送，本段再補一項教學條件：裝置後來有寫入需求，已另行查詢並取得 R=W=1 的有效轉譯，接著在 TC0、TC1 發出相關 Posted Writes。裝置用這兩個 TC 的回覆完成所需推送。Figure 10-5 示範一筆 Request 對應多筆 Invalidate Completion；依 Figures 10-21／10-22 解碼，此處的回覆是 Msg，Message Code=02h，依 ID 路由，不是一般 Cpl。ITag Vector 的 bit3 對應 ITag=3：

TC

Traffic Class，流量類別

兩筆 CC（Completion Count，失效完成訊息總數）都為 2，ITag Vector 都是 00000008h。第一筆只收齊一部分；TA 收到兩筆後，才可把本次失效視為完成並釋放這個 ITag。若 CC 編碼為零，表示八筆，不能解成不需要回覆。這個 ITag 與 Memory Request 的 Tag、PRI 的 PRG Index 都是不同機制。

前述條件保證的是規格定義的失效與推送範圍，不是應用資料已持久保存的保證；記憶體回收仍須配合平台生命週期。ATS Capability 存在時，即使 ATS Enable=0，Function 仍須能接受失效並回覆；Bus Master Enable=0 也不免除這項責任。不能因 Enable 快照為零，就把 Invalidate Completion 當成不合法。

Base 6.0 §10.1.1，Figures 10-4／10-5，pp.1474–1476；§§10.3–10.3.6，Figures 10-18–10-22，pp.1497–1503；§10.3.8，p.1505。

有 Read 權限，為何還要檢查 Priv 和 Exe？

Figure 10-14 的 R、W 說明可使用哪些存取類型；Priv（Privileged Mode Access，特權模式存取）指出這些權限適用於哪一種特權層級，Exe（Execute Permitted）則描述該範圍的執行權限。特權與非特權兩組權限彼此獨立，不能由其中一組推算另一組。

【模擬資料】先假設 PASID=21h 的 Translation Request 未要求執行或特權模式，兩個 Requested bit 的有效值都為 0。如果回覆項目的 Exe=1 或 Priv=1，就與對應欄位的規則不符。Function 可選擇執行規格列出的個別檢查；某項已實作的檢查若失敗，須回報 Unexpected Completion（非預期完成）。這些檢查是可選的，不能只憑未看到錯誤紀錄，就認定回覆符合所有條件。

再看正常回覆如何成立：Exe=1 要求 TA 支援執行權限、Request 的 Execute Requested 有效值為 1，而且回覆的 R=1。Priv=1 則要求 TA 支援特權模式，且 Request 的 Privileged Mode Requested 有效值為 1。有效值必須連同對應模式的 PASID TLP Prefix 或 OHC-A1 及其啟用條件判讀；不是只看某個位元的原始值。

Global=1 允許 Function 將映射作為同一 Function 的所有 PASID 共用映射；Function 也可以選擇只建立非 Global 映射。使用 Global 的 Function 必須支援 Global Invalidate，而且 Global=1 的回覆只可對應帶 PASID 的 Translation Request。系統如何定義特權模式或執行程式，仍需平台文件說明。

Base 6.0 §10.2.3、Figure 10-14／Table 10-3，pp.1485–1486；§§10.2.3.6–10.2.3.8，pp.1489–1491。

映射位址沒變，為什麼還可能需要 Invalidate？

先回顧案例：ATS Control 的 AMAE=0，因此先前沒有使用 ATS Memory Attributes（AMA，轉譯隨附的記憶體屬性）。現在改看另一個模擬情境：假設 Requester 和 TA 都已支援並啟用 AMA，ATC 也保存了某頁的轉譯及 AMA；之後平台修改該頁的 AMA，但轉譯位址不變。

AMA 值與 Completer 有關，具體意義由實作決定，Requester、ATC 和 TA 不應自行解讀數值。支援 AMA 的 ATC 可隨轉譯一起保存它；如果可能已被快取的頁面之 AMA 改變，軟體必須發出涵蓋該頁的 ATS Invalidation，讓 ATC 不再使用舊值。是否需要失效，不能只比較轉譯位址有沒有變。

回到 Figure 10-17：Translation Completion 可提供 AMA，Endpoint 之後可透過 TPH TLP Prefix 隨 Memory Read／Write 提供 AMA，TA 因此可能省下查詢。這張圖是實作說明，實際 Completer 對某個 AMA 值的處理以及 TA 如何偵測支援、啟用 AMA，仍由實作或平台文件決定。Requester 與 TA 未同時啟用時，AMA 的預設值是 000b。

TPH

TLP Processing Hints，封包處理提示

Base 6.0 §§10.1.4、10.2.3.9，Figure 10-17，pp.1478、1493–1495；ATS Capability／Control 見 §10.5.1，pp.1513–1516。

同一段位址，哪些 PASID 的快取會失效？

先回到 Figure 10-20：Invalidate Request 的資料指出未轉譯位址範圍；Global Invalidate 欄位與要求是否帶 PASID 一起決定範圍。以下是作者建立的教學假設：Function 處於 D0、PASID Enable 已設置，目標 Function 支援 Global Invalidate；位址範圍含 40001000h，PASID 21h 與 22h 均有效。

手機閱讀時，可左右滑動表格查看完整內容。

若 Function 不支援 Global Invalidate，帶 PASID 的要求中該 bit 由 ATC 忽略，依 §10.3.8 處理以指定 PASID 查得的範圍內項目；要求不帶 PASID 時，該 bit 是 Reserved。沒有符合的項目，仍須回覆 Invalidate Completion。PASID Enable 為 0 時，規格也要求回覆；超出 Max PASID Width 範圍的 PASID 則可能被回報為 UR。

以上是訊息所要求的快取處理範圍；在途 Read、Posted Write 與 Completion 的條件仍要依前一節完成。Base 6.0 §10.3.1、§10.3.8，Figure 10-20，文件／PDF pp.1498、1505。

沒有收到失效訊息，快取也可能失效嗎？

會。§10.3.7 列出由事件直接引起的隱含失效；這些事件不會另外送出 Invalidate Completion Message。

手機閱讀時，可左右滑動表格查看完整內容。

例如，停止使用 PASID 21h 與重新啟用 ATS 都可能影響同一項快取，但兩者影響的範圍不同；單憑「沒有看到失效回覆」不能判定快取仍有效。停止或重用 PASID 還要完成 §6.20.1 的協調，不能以隱含失效取代在途工作的處理。Base 6.0 §10.3.7，文件／PDF p.1504。

舊轉譯回覆與失效要求交錯時，ATC 怎麼辦？

教學情境：Endpoint 已送出涵蓋 40001000h 的 Translation Request，回覆尚未到達；平台接著針對重疊範圍送出 Invalidate Request。兩者可能使用不同 TC，Link 不會替它們提供一般的跨 TC 順序。

1. ATC 以 §10.3.6 的範圍規則，比對每個尚未完成的 Translation Request 與到達的 Invalidate Request。若有重疊，標記該查詢無效。
2. 對應結果必須按規定捨棄，避免失效完成後又將舊映射留在 ATC。若回覆在 Invalidate Completion 送出前先到，規格允許實作暫時使用結果，但仍須滿足 §10.3.3 對新要求、在途 Read 和 Posted Write 的條件。
3. 確認相關工作符合完成條件後，才送出 Invalidate Completion；平台收齊要求的全部回覆後，才把該次失效視為完成。

因此，在此案例中「收到一筆轉譯回覆」和「平台已完成失效交換」是不同時間點。若啟用 Shadow Functions（影子功能），§10.3.3 也把 Function 與其 Shadows 的相關要求納入完成條件；一次失效可針對其中一者提出，對應的 Posted Write 推送仍須依規格處理。Base 6.0 §10.3.3、§10.3.6，文件／PDF pp.1501、1503–1504。

Invalidate Queue Depth=4，代表最多只能接受四個要求嗎？

不宜把不同機制合成同一個數字。Invalidate Queue Depth（失效佇列深度）描述 Function 在對 Link 施加反壓前可緩衝的失效要求數；00000b 表示此非 VF Function 不需要這種 Invalidate Flow Control；Table 10-10 將非 VF 的零值解讀為可接受 32 筆，而 VF 的欄位固定為零、應讀相關 PF 的值。實際排列在輸入端、輸出端或兩者之間，由實作決定。

§10.3.4 禁止 Function 為了送出先前的 Invalidate Completion，才接受下一筆 Invalidate Request：兩者都是 Posted 交易，這種相依可能造成死結。規格的實作說明指出，單一 TA 對同一 ATC 最多有 32 筆尚未完成的失效；這個上限不要求輸入佇列本身一定是 32 格。

SR-IOV 情境要另外看 PF 與 VF 的共用範圍：所有關聯 VF 共用 PF 的 Invalidation Request queue；PF 的 Invalidate Queue Depth 為非零時，TA 必須讓指向該共用佇列、尚未完成的總數不超過該值。本章前面假設的值為 4；若實際是 PF／VF 共用配置，就要合計相關 Function 的要求，不能替每個 VF 各算四筆。

SR-IOV

Single Root I/O Virtualization，單根I/O虛擬化

Invalidate Completion 可在相同 TC、相同 CC 等條件成立時，用 ITag Vector 的多個 bit 合併回覆；拆成多個片段時，Requester ID、CC 和 ITag Vector 必須一致。合併訊息仍要讓 TA 為每個 ITag 收齊所需的回覆。Base 6.0 §10.3.2、§10.3.4–§10.3.5，文件／PDF pp.1500–1503。

頁面尚未駐留時，PRI 如何接回 ATS？

失效完成後，裝置重新查詢 40001000h 的轉譯，這次收到 R=W=0 的回覆。平台另提供一項資訊：接下來工作需要的 40001000h 與 40002000h 兩頁尚未駐留，而這個 Function 具有合法讀取用途。缺頁是本段另設的教學條件，不能單憑 R=W=0 判定。

依 §10.4，PRI 可請平台準備頁面。兩筆 Page Request 均使用 PASID=21h、R=1、W=0、PRG（Page Request Group，頁面要求群組）Index=005h；第一筆 L=0，最後一筆 L=1。本例 PRG Response PASID Required=1，所以成功回覆也須帶相同 PASID。

RID

Routing ID，封包使用的路由識別碼

Page Request 使用 Code=04h、Route to Root Complex；PRG Response 使用 Code=05h、Route by ID。兩者都須走 TC0。依 Non-Flit 的 Figures 10-23／10-27 或 Flit 的 Figures 10-24／10-28 讀取，Page Address、PRG Index 與回覆 Code 都有自己的欄位，不是一般 Memory Completion。

Table 10-8 的 Success=0000b 表示這個群組所有頁面已成功駐留，不回傳實體頁框。案例接著重發 ATS，假設新的有效 4 KiB 映射基址為 A0000000h，原本 offset=234h 的存取才改用 A0000234h。這個新基址來自新的 Translation Completion，不是從 PRG Response 解碼。

若群組中有一頁無法滿足，介面沒有「回一半成功」的格式；須依整組 Response Code 處理。Invalid Request=0001b 表示頁面不存在或權限無法給予，在映射未改變前重送不會成功；Response Failure=1111b 則是介面終止失敗，須依規則恢復。不同 PRG 不保證按送出順序完成。

Base 6.0 §§10.4–10.4.2.2，Figures 10-23／10-24、10-27／10-28，Tables 10-6–10-8，pp.1505–1513。

兩頁放同一群組，為何還是要先留兩份額度？

Outstanding Page Request Allocation=3 表示這個介面可同時保留三筆尚未完成的 Page Request，不是三個群組。§10.5.2.5 要求在開始一個 PRG 前，先預留該群組全部所需額度。因此本例開始前便為兩筆要求保留兩份；下表把「已送出」和「預留但還沒送出」分開：

最後只收到一筆 PRG Success，卻一次歸還本組兩筆 Page Request 的額度；PRG Index 也因此可再使用。若只剩一份可用額度，不能先送兩頁群組的第一頁，再等額度回來才送第二頁。Page Request 額度也不是 Chapter 17 的逐 Link Flow Control Credit，兩者須分開追蹤。

同一 Function 的 Allocation 在所有 PASID 間共用，不是每個 PASID 各有三份。對 SR-IOV，Page Request Interface 可由 PF 與 VFs 共用，但每筆封包仍保留實際要求 Function 的 RID；ATS 的 VF Capability Enable 又可各自控制，不能只讀 PF 就代替所有 VF。這是 Chapter 26 的作用範圍在此處的延伸。

Base 6.0 §10.4，p.1506；§10.5.1，p.1513；§10.5.2，p.1516；§10.5.2.5 Outstanding Page Request Allocation (Offset 0Ch)，p.1520。

停止 PASID 21h 時，還沒回來的頁面要求怎麼處理？

教學情境：沿用前面的 PASID 21h 與兩頁 PRG，但改成兩筆 Page Request 都已送出、最後一筆的 L=1，而 PRG Response 尚未到達。裝置準備停止使用這個 PASID；這不等於整個 Page Request Interface 已停止。

§10.4.1.2 提供兩條路徑。兩者都先停止為 21h 排入新 Page Request，並送完尚未結束的多頁群組，包含 L=1 的最後一筆。接下來的差異如下：

手機閱讀時，可左右滑動表格查看完整內容。

Stop Marker 是特定 PASID 的邊界訊息；Host 收到它時，先前屬於該 PASID 的 Page Request 已送達，之後使用相同 PASID 的要求屬於新的使用世代。這個訊息本身沒有回覆、不帶 PRG Index，也不消耗 Page Request Allocation。舊要求的額度不會因為送出 Marker 就立刻歸還。

停止或重用 PASID 還涉及其他已發出的交易與裝置／平台協調；此處只帶讀 PRI 的額外要求。Base 6.0 §10.4.1.2–§10.4.1.2.1、§10.5.2.5，文件／PDF pp.1509–1510、1520。

Trace 裡的 Stop Marker，怎麼和一般 Page Request 分開？

先確認封包是 Page Request Message，再看 Figures 10-25／10-26：Stop Marker 的 L=1、W=0、R=0，Marker Type=00000b，而且必須使用 TC0、Relaxed Ordering=0。Non-Flit Mode 用 PASID Prefix；Flit Mode 用帶 PASID 的 OHC-A1。

這組欄位代表停止邊界，不是請 Host 載入一個沒有讀寫權限的頁面。Stop Marker 的未轉譯位址與 PRG Index 上方位元是 Reserved，不應拿它們當頁面位址或群組編號。

例如，若 Host 沒有對應的 PASID 停止要求，或同一 PASID 尚有多頁群組沒有送出 L=1 的最後一筆，收到 Stop Marker 的行為為 undefined（規格未定義）；不能自行推成一定成功或一定回錯。Base 6.0 §10.4.1.2.1、Figures 10-25／10-26，文件／PDF pp.1509–1510。

PRG Response 回來後，要先看哪些欄位？

先依 Figure 10-27 或 10-28 確認模式與目的 Function，再用 PRG Index 找到仍在等待的群組。若 Page Request 帶 PASID，是否期待 Response 也帶 PASID，要查 Status 的 PRG Response PASID Required；兩端使用不符合該欄位的格式，Function 行為可能未定義。

同一 PRG 若有任何一筆要求帶 PASID，其所有 Page Request 都必須帶相同 PASID；不一致的行為未定義。 帶 PASID 的 Page Request 若設置 Execute Requested，也必須設置 R；W=1 則需要明確的寫入授權，因為 Host 可以將頁面標記為 dirty（已修改）。當 PRG Response PASID Required=0 時，Response 不帶 PASID，Function 的 PRG Index 在各 PASID 間共用；不能把相同 Index 當成每個 PASID 各有一份。

再查 Table 10-8 的 Response Code：0000b 是整組 Success；0001b 是 Invalid Request；0010b–1110b 的未使用編碼要按 Response Failure 處理；1111b 是 Response Failure。Failure 會終止該介面的正常頁面要求服務，在重新啟用前，後續 PRG Response 會被忽略。

如果正常封包的 PRG Index 沒有對應尚未完成的群組，Status 會記錄 Unexpected Page Request Group Index（UPRGI）。收到 Success 仍須重新查 ATS 才能取得轉譯結果。Base 6.0 §10.4.1.1、§10.4.2–§10.4.2.2、Table 10-8，文件／PDF pp.1508、1511–1513。

停用整個 Page Request Interface，要怎麼讀 Enable 和 Stopped？

SR-IOV 若採由 PF 提供、與其 VFs 共用的 Page Request Interface，能力結構由 PF 實作，VFs 不得各自實作。每筆 Page Request 仍帶實際發出要求的 PF 或 VF Requester ID；對應 PRG Response 的目的識別也要指向該 Function。Base 6.0 §10.5.2，文件／PDF p.1516。

這裡處理的是整個介面，與前面停止單一 PASID 的 Stop Marker 不同。從 Figure 10-33 定位結構，再用 Figures 10-35／10-36 與 Tables 10-14／10-15 讀 Control、Status。 Figure 10-34 的 Header 中，ID 是 0013h、Version 是 1，bits 31:20 的 Next Capability Offset 則以 Configuration Space 起點為基準。

手機閱讀時，可左右滑動表格查看完整內容。

只有 Enable 已清除，或同一次寫入同時清除 Enable 並設置 Reset，寫 Reset=1 才會清除介面內部的額度計數與待處理狀態；Enable 保持為 1 時，寫 Reset 不啟動動作。若介面尚未成功停止便重新啟用，結果為 indeterminate（無法確定）。

Status 的 Response Failure 和 UPRGI 分別位於 bit 0、bit 1，都是 RW1C（寫入 1 清除）的事件欄位；重新啟用介面時，規格也會清除這些狀態。PF 與 VF 共用介面時，相關 Function 的這兩類事件記錄在 PF。

Outstanding Page Request Capacity 是唯讀上限，Allocation 是啟用前配置的額度；Allocation 不得在 Enable=1 時更改，也不得寫入大於 Capacity 的值。若啟用 Shadow Functions，Allocation 由主 Function 與啟用的 Shadows 共用；停止某個 PASID 不會直接歸還其已用額度。

Base 6.0 §10.5.2.1–§10.5.2.5、Figures 10-33–10-36、Tables 10-13–10-15，文件／PDF pp.1517–1520。

下次遇到轉譯問題，如何安排查閱順序？

先確認 RID、PASID、模式及平台服務，再核對各結構的 Support／Enable。沿 Table 10-1 看 AT 類型，依原 Request／Tag 配對 Translation Completion，先讀 S、R、W、U 與上下文，再決定實際 Memory Request。映射有改變就追 Invalidate 的範圍、ITag Vector、CC 與在途交易；有 Page Request 才另追 PRG、Last、PASID、額度與 Response Code。

若 PASID 準備停用或重用，還須依 §6.20.1 及 Chapter 10 的停止規則處理舊 Request、Posted Writes、ATC 與 Page Requests；改一個識別碼並不會自行結束舊工作。Reset 與 ATS Enable 從零變一也會引起隱含失效，不能拿先前快照當成目前快取內容。

版本與完整來源路線

本章以 PCI Express Base Specification Revision 6.0（6.0-1.0-PUB）為準，文件印刷頁與 PDF 檢視器頁碼相同。拓撲、設定、映射、封包欄位及額度推演皆為作者建立，未執行硬體操作或平台頁面服務。本章沒有以外部網站作技術依據。