任務列表

任務可能包含以下欄位

  • Complexity: 描述所需的 Rust 熟悉程度和/或相應的核心 API 或子系統。 有四種不同的複雜度，Beginner、Intermediate、Advanced 和 Expert。

  • Reference: 對其他任務的引用。

  • Link: 外部資源的連結。

  • Contact: 可以聯絡以獲取有關任務更多資訊的人員。

啟用 (Rust)

與 nova-core 沒有直接關係，但卻是所需 API 方面的前提條件的任務。

FromPrimitive API

有時需要將數字轉換為列舉或結構的值。

nova-core 中的一個很好的例子是 Chipset 列舉型別，它定義了值 AD102。 當探測 GPU 時，可以從某個暫存器中讀取值 0x192，指示晶片組 AD102。 因此，應該從數字 0x192 匯出列舉值 AD102。 目前，nova-core 使用自定義實現（對於此，使用 Chipset::from_u32）。

相反，最好擁有類似於來自 num crate 的 FromPrimitive 特徵 [1]。

擁有這種泛化也有助於實現一個通用宏，該宏自動生成值和數字之間的相應對映。

複雜度：初級
連結：https://docs.rs/num/latest/num/trait.FromPrimitive.html

通用暫存器抽象

研究如何透過通用宏自動生成暫存器常量和結構。

例子

register!(BOOT0, 0x0, u32, pci::Bar<SIZE>, Fields [
   MINOR_REVISION(3:0, RO),
   MAJOR_REVISION(7:4, RO),
   REVISION(7:0, RO), // Virtual register combining major and minor rev.
])

這可以擴充套件成類似的東西

const BOOT0_OFFSET: usize = 0x00000000;
const BOOT0_MINOR_REVISION_SHIFT: u8 = 0;
const BOOT0_MINOR_REVISION_MASK: u32 = 0x0000000f;
const BOOT0_MAJOR_REVISION_SHIFT: u8 = 4;
const BOOT0_MAJOR_REVISION_MASK: u32 = 0x000000f0;
const BOOT0_REVISION_SHIFT: u8 = BOOT0_MINOR_REVISION_SHIFT;
const BOOT0_REVISION_MASK: u32 = BOOT0_MINOR_REVISION_MASK | BOOT0_MAJOR_REVISION_MASK;

struct Boot0(u32);

impl Boot0 {
   #[inline]
   fn read(bar: &RevocableGuard<'_, pci::Bar<SIZE>>) -> Self {
      Self(bar.readl(BOOT0_OFFSET))
   }

   #[inline]
   fn minor_revision(&self) -> u32 {
      (self.0 & BOOT0_MINOR_REVISION_MASK) >> BOOT0_MINOR_REVISION_SHIFT
   }

   #[inline]
   fn major_revision(&self) -> u32 {
      (self.0 & BOOT0_MAJOR_REVISION_MASK) >> BOOT0_MAJOR_REVISION_SHIFT
   }

   #[inline]
   fn revision(&self) -> u32 {
      (self.0 & BOOT0_REVISION_MASK) >> BOOT0_REVISION_SHIFT
   }
}

用法

let bar = bar.try_access().ok_or(ENXIO)?;

let boot0 = Boot0::read(&bar);
pr_info!("Revision: {}\n", boot0.revision());

注意：一個正在進行中的實現目前位於 drivers/gpu/nova-core/regs/macros.rs 中，並在 nova-core 中使用。 如果能改進它（可能使用 proc 宏）並將其移動到 kernel crate，以便其他元件也可以使用它，那就太好了。

複雜度：高階
聯絡人：Alexandre Courbot

延遲/睡眠抽象

核心 delay() 和 sleep() 函式的 Rust 抽象。

FUJITA Tomonori 計劃處理 read_poll_timeout_atomic()（及其朋友）[1] 的抽象。

複雜度：初級
連結：https://lore.kernel.org/netdev/20250228.080550.354359820929821928.fujita.tomonori@gmail.com/ [1]

IRQ 抽象

IRQ 處理的 Rust 抽象。

Daniel Almeida [1] 正在積極進行 “核心” 抽象以請求 IRQ。

除了可選的審查和測試工作外，還需要研究圍繞這些核心抽象的所需的 pci::Device 程式碼。

複雜度：中級
連結：https://lore.kernel.org/lkml/20250122163932.46697-1-daniel.almeida@collabora.com/ [1]
聯絡人：Daniel Almeida

外部頁面的頁面抽象

由 Rust 頁面抽象建立的、沒有直接所有權的頁面的 Rust 抽象。

Abdiel Janulgue [1] 和 Lina [2] 正在積極進行中。

複雜度：高階
連結：https://lore.kernel.org/linux-mm/20241119112408.779243-1-abdiel.janulgue@gmail.com/ [1]
連結：https://lore.kernel.org/rust-for-linux/20250202-rust-page-v1-0-e3170d7fe55e@asahilina.net/ [2]

Scatterlist / sg_table 抽象

scatterlist / sg_table 的 Rust 抽象。

Abdiel Janulgue 先前做過一些工作，但尚未釋出到郵件列表。

複雜度：中級
聯絡人：Abdiel Janulgue

ELF 工具

ELF 標頭表示的 Rust 實現，用於從 ELF 格式的映像中檢索節標頭表、名稱和資料。

Abdiel Janulgue 先前做過一些工作，但尚未釋出到郵件列表。

複雜度：初級
聯絡人：Abdiel Janulgue

PCI MISC API

透過 SR-IOV、配置空間、功能、MSI API 抽象來擴充套件現有的 PCI 裝置/驅動程式抽象。

複雜度：初級

輔助匯流排抽象

輔助匯流排 API 的 Rust 抽象。

這是將 nova-core 連線到 nova-drm 驅動程式所必需的。

複雜度：中級

Debugfs 抽象

debugfs API 的 Rust 抽象。

參考：匯出 GSP 日誌緩衝區
複雜度：中級

GPU（通用）

解析韌體標頭

解析從檔案系統載入的韌體檔案中的 ELF 標頭。

參考：ELF 工具
複雜度：初級
聯絡人：Abdiel Janulgue

構建 radix3 頁表

構建 radix3 頁表以對映韌體。

複雜度：中級
聯絡人：Abdiel Janulgue

vBIOS 支援

解析 vBIOS 並探測驅動程式初始化所需的結構。

聯絡人：Dave Airlie
參考：Vec 擴充套件
複雜度：中級

初始 Devinit 支援

實現 BIOS 裝置初始化，即記憶體大小調整、等待、PLL 配置。

聯絡人：Dave Airlie
複雜度：初級

引導 Falcon 控制器

載入和執行 falcon (sec2) 韌體映像的基礎架構； 處理 GSP falcon 處理器和 fwsec 載入。

複雜度：高階
聯絡人：Dave Airlie

GPU 定時器支援

支援 GPU 的內部定時器外設。

複雜度：初級
聯絡人：Dave Airlie

MMU / PT 管理

研究 MMU / 頁表管理的架構。

我們需要考慮 nova-drm 需要相當精細的控制，尤其是在鎖定方面，以便能夠實現非同步 Vulkan 佇列。

雖然通常共享相應的程式碼是可取的，但需要評估共享相應的程式碼如何（以及是否）是 expedient。

複雜度：專家

VRAM 記憶體分配器

調查 VRAM 記憶體分配器的選項。

一些可能的選項

  • Rust 抽象 - RB 樹（區間樹）/ drm_mm - maple_tree

  • 本機 Rust 集合

複雜度：高階

例項記憶體

實現對用於儲存頁表的 instmem (bar2) 的支援。

複雜度：中級
聯絡人：Dave Airlie

GPU 系統處理器 (GSP)

匯出 GSP 日誌緩衝區

Timur Tabi [1] 最近的補丁增加了透過 debugfs 公開 GSP-RM 日誌緩衝區（即使在未能探測驅動程式之後）的支援。

對於 nova-core 來說，這在早期也是一個有趣的功能。

連結：https://lore.kernel.org/nouveau/20241030202952.694055-2-ttabi@nvidia.com/ [1]
參考：Debugfs 抽象
複雜度：中級

GSP 韌體抽象

GSP-RM 韌體 API 不穩定，並且可能在資料結構和語義方面從版本到版本不相容地更改。

這個問題是使用 Rust 作為 nova-core 的一大動機之一，因為事實證明 Rust 的過程宏功能提供了一種相當優雅的方式來解決這個問題

  1. 從 C 標頭在每個版本的單獨名稱空間中生成 Rust 結構

  2. 構建實現韌體介面的抽象結構（在通用名稱空間中）； 使用版本識別符號註釋實現中的差異

  3. 使用過程宏從此抽象中生成每個版本的實際實現

  4. 在執行時例項化正確的版本型別（可以確保所有型別都具有相同的介面，因為它由通用特徵定義）

在 nova-core PoC 驅動程式的上下文中，存在此模式的 PoC 實現。

此任務旨在改進該功能並最好將其通用化，以便其他驅動程式也可以使用它。

複雜度：專家

GSP 訊息佇列

實現用於核心驅動程式和 GSP 之間通訊的低級別 GSP 訊息佇列（命令、狀態）。

複雜度：高階
聯絡人：Dave Airlie

引導 GSP

呼叫引導韌體以引導 GSP 處理器； 執行初始控制訊息。

複雜度：中級
聯絡人：Dave Airlie

客戶端/裝置 API

實現用於客戶端/裝置分配的 GSP 訊息介面以及相應的客戶端和裝置分配 API。

複雜度：中級
聯絡人：Dave Airlie

Bar PDE 處理

同步核心驅動程式和 GSP 之間的 BAR 頁表處理。

複雜度：初級
聯絡人：Dave Airlie

FIFO 引擎

實現對 FIFO 引擎的支援，即相應的 GSP 訊息介面，並提供用於 chid 分配和通道處理的 API。

複雜度：高階
聯絡人：Dave Airlie

GR 引擎

實現對圖形引擎的支援，即相應的 GSP 訊息介面，並提供用於（黃金）上下文建立和提升的 API。

複雜度：高階
聯絡人：Dave Airlie

CE 引擎

實現對複製引擎的支援，即相應的 GSP 訊息介面。

複雜度：中級
聯絡人：Dave Airlie

VFN IRQ 控制器

支援 VFN 中斷控制器。

複雜度：中級
聯絡人：Dave Airlie

外部 API

nova-core 基本 API

研究連線二級驅動程式（即 vGPU 管理器和 nova-drm）的 API 的常見部分。

複雜度：高階

vGPU 管理器 API

研究 vGPU 管理器所需的、基本 API 未涵蓋的 API 部分。

複雜度：高階

nova-core C API

為 vGPU 管理器驅動程式所需的 API 實現一個 C 包裝器。

複雜度：中級

測試

CI 管道

調查持續整合測試的選項。

這可以從執行 KUnit 測試到執行（圖形）CTS，再到啟動（多個）訪客虛擬機器以測試 VFIO 用例。

還值得考慮引入一個新的測試套件，直接位於 uAPI 之上，以進行更有針對性的測試和除錯。 可以選擇與 Mesa 專案進行協作/共享程式碼。

複雜度：高階