多功能、ARI、SR-IOV 與 Shadow Functions

多個 Function 共用 Link，身分與資源仍分別管理

這章先建立哪一組對象？

沿用 Chapter 1 的 Port／Link 與 Chapter 4 的資源配置：Root Port 經 Switch 連到 Endpoint。Endpoint 只有一個 Port，內含一個 PF 與三個將要建立的 VF；每個 Function 的 Configuration、交易身分與資源要分別看，Link Speed、Width 與 LTSSM 則仍屬共用的 Link。

LTSSM

Link Training and Status State Machine，鏈結訓練與狀態機

【模擬資料】以下資料為教學用途建立，不代表特定硬體或平台。假設 PF 處於 D0，RID=0300h，且是本裝置最低編號的 PF。軟體具備 ARI 支援，所需 Bus Number 與上層資源 Window 均可配置，沒有其他 PF／VF 占用本例身分。初始 VF Enable=0、VF MSE=0；本例不實作 VF Resizable BAR、不支援 FRS，也沒有採用較短的回報或平台 VF Enable Time。

FRS

Function Readiness Status，功能就緒狀態

這份 Base 6.0 的 Chapter 9 已定義 SR-IOV 架構、配置與生命週期；主要答案直接依本版查閱。虛擬機分配政策、IOMMU 隔離與裝置內部排程仍須平台或裝置資料，不能由 PF／VF 數量推論。

0314h 是 Device 2、Function 4，還是 Function 20？

先讀 §6.13：傳統 16-bit RID（Routing ID，路由識別碼）分成 Bus [15:8]、Device [7:3]、Function [2:0]；ARI 把低 8 bits 合併成 Function Number，RID 的總長度不變。因此同一個 0314h，可被傳統顯示方式拆成 Bus=03h、Device=02h、Function=04h，在 ARI 裝置中則表示 Bus=03h、Function=14h，也就是十進位 20。顯示成哪種格式，不會創造另一個實體 Device。ARI 本身也不建立 VF；建立 VF 仍須由所屬 PF 的 SR-IOV Control 處理。

接著用 Figure 6-13 Example System Topology with ARI Devices 找到緊鄰 Endpoint 上方的 Switch Downstream Port。查該 Port 的 Device Capabilities 2.ARI Forwarding Supported [5]，再查 Device Control 2.ARI Forwarding Enable [5]。本例這兩個 bit 都為一；Root Port 上方那條通往 Switch 的 Link，不因最下游是 ARI 裝置就必須同樣啟用。

裝置端另沿 ARI Extended Capability（ID=000Eh、Version=1）讀取能力。Table 7-157 的 Next Function Number 由 Function 0 開始串非 VF Functions；VF 的這個欄位為 undefined，須改走 First VF Offset／VF Stride，Shadow Functions 也不加入這條鏈。因此不能把 ARI 鏈列出的 Function 數直接當成 VF 數。

PF 的 ARI Capable Hierarchy 又是另一個 bit：它提示裝置，緊鄰上方 Port 已啟用 ARI。軟體應讓它與該 Port 的 ARI Forwarding Enable 一致；本例設為一。它在最低編號 PF 控制整個裝置，不能在任一 PF 的 VF Enable 已為一時改變。這個設定不會取代上方 Port 的轉送控制。

Base 6.0 §6.13，pp.762–765；Figure 6-13，p.764；§7.8.8，Figures 7-181–7-184、Tables 7-156–7-158，pp.1146–1148；§7.5.3.15，p.990；§7.5.3.16，p.996；§9.3.3.3.5，pp.1457–1458。

ARI Function 如何取得發送要求時的 Bus Number？

前一節已將 0314h 拆成 ARI 的 Bus 03h 與 Function Number 14h。現在接到 §2.2.6.2：ARI Device 的 Functions 只要求擷取 Type 0 Configuration Write 中的 Bus Number；ARI Requester ID 的低 8 bits 是 Function Number，沒有另外的 Device Number 欄位。

此案例使用 Non-Flit Mode，沒有展開 Flit Mode 的 Segment 欄位。初次設定與一般非 ARI Function 的對照見 Chapter 3；Bus／Function 身分更新與 VF 啟用仍是不同步驟。

PCI Express Base 6.0 §2.2.6.2，文件頁／PDF 頁 156–157，尤其是 ARI 相關註腳；§6.13 Alternative Routing-ID Interpretation，pp.760–762；§6.4 Device Synchronization，pp.717–718。

建立三個 VF 前，要先讀哪些欄位？

在 PF 中沿 Extended Capability 鏈找 ID=0010h、Version=1，將起點記為 S。Figure 9-10 SR-IOV Extended Capability 把 Control、數量、RID 與資源欄位放在同一個結構，但讀取寬度不同。以下數量與 offset／stride 為 16-bit，Page Sizes 為 32-bit：

TotalVFs 是最大數量，NumVFs 才是本次要建立的數量。NumVFs 的初始值為 undefined，軟體須主動設定；本例 3≤8。只有 VF Enable=0 時才能寫 NumVFs，寫入超過 TotalVFs 或在啟用中改數量，結果皆為 undefined。

System Page Size=00000010h 是選取 bit4，表示 2⁴⁺¹²=65,536 bytes＝64 KiB，並不是 16 bytes。它必須只設一個受支援的 bit；零、多個 bit 或未宣告的 bit 都會導致 undefined。本例的 Supported Page Sizes 包含規格要求的六種大小。Page Size 也須在 VF Enable=0 時寫入；改變後所有 VF BARn 內容為 indeterminate，須重新探測與配置。

NumVFs 與 ARI Capable Hierarchy 都可能影響 First VF Offset／VF Stride，所以先完成這些設定，再讀下面的 RID 資料；不能沿用另一組 NumVFs 時保存的 offset。

Base 6.0 §§9.2.1.1–9.2.1.2，pp.1445–1447；§9.3.3.1，Figures 9-10／9-11、Table 9-2，pp.1451–1452；§9.3.3.7，p.1459；§§9.3.3.12–9.3.3.14，pp.1462–1463。

第 3 個 VF 的身分怎麼找？

現在才用 Table 9-1 VF Routing ID Algorithm：第 N 個 VF 的 RID＝PF RID＋First VF Offset＋(N−1)×VF Stride，採 16-bit 無號運算，捨棄進位。接續已配置的 NumVFs=3、PF RID=0300h、Offset=0010h、Stride=0002h，得到：

這裡從 VF 1 開始編號，對應 Table 9-1；若工具用從零開始的 VF index，須先對照編號。Stride=2 表示 RID 每次加二，不表示 BAR 每次加兩個 bytes。表中的傳統拆法只是同一個位元樣式的顯示，本例以 ARI 的 8-bit Function Number 解讀。

三個 VF 都留在 Bus 03h；其他配置可能跨 Bus，須在啟用前保留足夠 Bus Numbers。所有 PF／VF 的 RID 必須互異，VF 也不得落在比所屬 PF 更小的 Bus Number。公式的 16-bit 回繞規則不代表軟體可以配置到更小的 Bus 或已被其他 Function 占用的身分。

Base 6.0 §9.2.1.2，Table 9-1，pp.1446–1447；§9.3.3.9 First VF Offset (Offset 14h)、§9.3.3.10 VF Stride (Offset 16h)，p.1461。

已知 RID 後，VF 3 的記憶體位址又怎麼找？

改看 Figure 9-9 BAR Space Example for Single BAR Device，將 PF 自己的普通 BAR 與 PF 內 SR-IOV 結構的 VF BAR 分開。VF 自己的 Type 0 Header BAR 全部固定讀零；要替這組 VF 配置資源，須操作 PF 的 VF BAR，不能把位址分別寫進每個 VF 的 Header BAR。

本例在選好 64 KiB System Page Size 後，對 VF BAR0／VF BAR1 這一組 64-bit、Prefetchable BAR 進行 sizing，讀回低 DW=FFFF000Ch、高 DW=FFFFFFFFh。低 4 bits 描述 BAR 類型，去除後得到 64-bit address mask=FFFFFFFFFFFF0000h；取 64-bit 反相再加一，得到每個 VF 的 aperture（位址視窗大小）=10000h＝64 KiB。

DW

Double Word，4 bytes的資料單位

再將第一個 VF 的基址配置為 90000000h，對應 VF BAR0=9000000Ch、VF BAR1=00000000h。後續起點依 §9.2.1.1.1 的公式：VF BAR base＋(VF編號−1)×per-VF aperture。這與前節的 RID 公式使用不同單位：

因此第 3 個 VF 的起點為 90020000h，完整資源範圍為 90020000h–9002FFFFh。三個 VF 合計 30000h＝192 KiB；這次映射數量採 NumVFs=3，不是直接乘最大 TotalVFs=8。軟體可另外預留更多空間供未來配置，但那是額外的資源政策。上游 Window 須涵蓋這次映射範圍，每個 VF 的大小與對齊也須符合選定的 System Page Size。

若裝置另有 VF Resizable BAR（ID=0024h、Version=1），它位於 PF，不能出現在 VF；普通 Resizable BAR 與 VF Resizable BAR 可同時存在、各管不同資源。改 VF BAR Size 前須先清 VF MSE，選受支援的大小，改後重新配置已變為 undefined 的 VF BAR，再按需求開啟 VF MSE。VF aperture 會反映 System Page Size 與 VF BAR Size 兩者要求的較大值，不能只改尺寸欄位就沿用舊基址。本例沒有使用這項可選能力。

Base 6.0 §9.2.1.1.1，Figure 9-9，pp.1445–1446；§9.3.3.14，pp.1462–1463；§7.5.1.2.1，Figures 7-10／7-11、Table 7-9，pp.928–930；§7.8.7，Figures 7-178–7-180、Tables 7-154／7-155，pp.1142–1145。

VF Enable 設為一，就能立刻讀 BAR 嗎？

還要分開確認初始化等待、Configuration 就緒與 Memory 解碼。本例在 PF 的 SR-IOV Control [4] 保留 ARI Capable Hierarchy=1，其他未列欄位假設為零：0010h 表示尚未啟用，0011h 表示 VF Enable=1、VF MSE=0，0019h 才同時開啟 VF MSE [3]。圖中的 RRS（Request Retry Status，要求稍後重試）走重試分支；SC（Successful Completion，成功完成狀態）才接到後續設定。

FRS

Function Readiness Status，功能就緒狀態

VF Enable 從零變一後，系統須先等至少 100 ms，或收到 PF 的 FRS（Function Readiness Status，功能就緒狀態）Message、Reason=VF Enabled，或已達規格允許的 VF Enable Time，才可對 VF 發 Request。本例沒有後兩種提早條件，因此 50 ms 時仍不送 Configuration Request。

120 ms 的 Configuration Request 回覆 RRS（Request Retry Status，要求稍後重試的狀態）。VF 允許在啟用後的 1.0 s 期限內，以 Configuration RRS 表示尚未準備；Root Complex／軟體也必須至少等 1.0 s，才能將無法對有效 Configuration Request 回 Successful Completion 的 VF 判為故障。這不是每次收到 RRS 就重設一秒計時。

180 ms 收到 SC（Successful Completion，成功完成狀態）後，本例已符合其中一項 Memory 就緒條件；但 VF MSE 仍為零，所以還不能存取 Memory Space。181 ms 設成 0019h，且 Function 專用初始化已完成，才進行對 VF 3 的 90020010h 存取。規格也允許由相應 FRS、等待 1.0 s 或適用的回報／平台 VF Enable Time 滿足其他 Memory 就緒路徑；單純等過 100 ms 並不等同這些條件。

一個 VF 曾成功回覆 Request 後，若沒有再停用或其他合法 Reset 條件，就不能再以 Configuration RRS 回覆 Configuration Request。若清除 VF Enable，則是銷毀 VF；在至少 1.0 s 過去，或收到 PF 的 FRS Reason=VF Disabled 之前，連 PF 內這個 SR-IOV Capability 的任何欄位都不能再存取。不能清除後立刻輪詢 Control 或改 NumVFs。

Base 6.0 §9.3.3.3，Figure 9-13、Table 9-4，pp.1454–1455；§9.3.3.3.1 VF Enable，pp.1455–1457；§9.3.3.3.4 VF MSE (Memory Space Enable)，p.1457。

VF 的 Vendor ID=FFFFh、MSE=0，是否代表沒有裝置？

對一般 Function，FFFFh Vendor ID 常用於判斷不存在；對 VF，§7.5.1.1.1／§7.5.1.1.2 卻要求原始 Configuration Vendor ID 與 Device ID 固定回 FFFFh。虛擬化軟體應分別採所屬 PF 的 Vendor ID 與 SR-IOV 結構的 VF Device ID 提供 VF 的身分。本例若在 180 ms 讀 Vendor ID，重點先看這筆 Completion 是否為 SC，再依 VF 欄位規則解讀 FFFFh，不能套用一般裝置的探測捷徑。

同樣地，VF 的 Command.Memory Space Enable 為 ROZ（Read Only Zero，固定讀零），Memory 解碼由 PF 的 VF MSE 控制整組 Active VFs；VF 的 I/O Space Enable 也固定零，VF 不支援 I/O Space。VF 自己的 Bus Master Enable 則管它能否發起 Memory Request，與讓主機讀取 VF BAR 的方向不同，不能用 PF 的 Bus Master Enable 代表所有 VF。

各自的 Bus Master Enable 與裝置條件都滿足後，兩個 VF 可以用同一個 Tag=05h 發出 Memory Read。回來的 Completion 須分別以 Requester ID=0310h／0312h 配對，不能因 Tag 一樣就視為同一筆。PF／VF 共用 Link 的速度正常，也無法代替個別 Function 的資源、BME、交易與裝置初始化檢查。

若需要中斷，再接回 Chapter 7 的 MSI／MSI-X。VF 可在有配置資源時使用 MSI、MSI-X 或兩者，但不得實作 INTx；內部資源分配、排程與虛擬機指派政策另由平台及裝置處理。

MSI

Message Signaled Interrupt，訊息中斷

MSI-X

Message Signaled Interrupts Extension，表格式訊息中斷

Base 6.0 §§7.5.1.1.1–7.5.1.1.3，Table 7-4，pp.917–918；§7.5.1.2.1，p.928；§9.2.1.4 Interrupt Resource Allocation，p.1449；PF／VF 路由身分與資源，pp.1440–1447。

重設 VF、重設 PF 與重新建立 VF，有什麼不同？

PF 處於 D0 時，新建立的 VFs 進入 D0uninitialized；PF 在較低電源狀態時，建立行為為 undefined。Conventional Reset 也會清除 VF Enable，使 VF 不再存在。這些行為與共用 Link 是否一直維持 L0 是不同層次，不能只看 Link Status 判斷 VF 的生命週期。

Base 6.0 §9.2.2 SR-IOV Reset Mechanisms、§§9.2.2.1–9.2.2.3，p.1449；§9.2.3 IOV Re-initialization and Reallocation，p.1450；§9.3.3.3.1，p.1456。

Shadow Function 為何會發 Request，卻查不到獨立 Configuration？

Shadow Functions（影子功能）借用尚未實作 Function 的 Requester ID 與 Tag 資源，讓原本的 Requester 容納更多 Outstanding Requests。它使用關聯 Function 的特性與設定，並不建立可獨立指派的 VF。先找 ID=002Dh、Version=1，再用 Figure 7-365 定位結構，讀 Tables 7-320–7-322。

接續模擬案例：假設 PF 0300h 額外實作一個 Shadow Function，且 0320h 尚未由任何 PF／VF／其他 Function 占用。Number of Shadow Functions 欄位讀零，採 N−1 編碼，表示一筆 Instance；第一筆在 H+0Ch，Shadow Function Number=0020h 是 16-bit BDF offset。用 0300h＋0020h＝0320h 算出新 Requester ID，這個欄位提供相對 offset，不能當成絕對 Function Number。

BDF

Bus／Device／Function，匯流排、裝置與功能識別

軟體已處理此身分的位址轉譯與存取控制，且主 Function 的 Phantom Functions Enabled=0、沒有 Outstanding Non-Posted Requests，才在本例開啟 Shadow Functions Enable。該 Control bit 在仍有 Outstanding Non-Posted Requests 時變更，或與 Phantom Functions Enabled 同時開啟，都會導致 undefined。

開啟後，可看到 Requester ID=0320h 的 Memory Read；一般 Posted Request 也可使用這份身分，但 MSI／MSI-X Request 不得使用 Shadow Function 的 Transaction ID 資源。對 0320h 的 Configuration 存取，在沒有其他優先錯誤時必須回 UR，而不是提供另一份獨立 Configuration Space。這與已建立 VF 的 SC／FFFFh 欄位情況不同。

Shadow Function 的 Number 大於 7 需要 ARI；非 ARI 時必須留在相同 Device。軟體也須預先更新地址轉譯資源，否則在 Request 發出時的行為為 undefined。故障分析時要把 0320h 對回關聯 PF 與這份 Capability，同時保留該 RID 在完整路徑上的檢查，不能只因它沒有可列舉的 Configuration 就忽略其 Request。

Base 6.0 §7.9.25 Shadow Functions Extended Capability，pp.1299–1303；Figures 7-365–7-369、Tables 7-319–7-322。首筆 offset 與 N−1 編碼以 §7.9.25.2／§7.9.25.4 的欄位規則為準。

版本、閱讀路線與文件邊界

本章依 PCI Express Base Specification Revision 6.0（6.0-1.0-PUB），文件印刷頁與 PDF 檢視器頁碼相同。拓撲、讀值、RID、BAR 與時間線均為作者建立，未操作實機。本章沒有以外部網站作技術依據。