← Documents Documentation/gpu/nova/core/todo.rst GitHub 원문 ↗

Linux 6.18.37 · GPU·DRM·Nova

Nova-core Task List

Nova-core의 Rust enablement, GPU·GSP 기능, 외부 API와 CI 작업을 정리한 전문 번역입니다.

Source pathDocumentation/gpu/nova/core/todo.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약·해설

todo.rst:1-429

Nova-core가 필요로 하는 Rust kernel abstraction, GPU·GSP 기능, second-level driver API와 CI 작업을 난이도·의존성·담당자와 함께 정리한 전문 번역입니다.

Task 영역
영역대표 task
Rust enablementFromPrimitive·register·IRQ·page·PCI·XArray·debugfs
GPU generalDevinit·MMU/PT·VRAM allocator·instance memory
GSPFirmware abstraction·queue·bootstrap·engine
External APIBase·vGPU manager·C wrapper
TestingKUnit·CTS·VFIO·uAPI suite

전체 TODO를 구현 계층별로 묶었습니다.

의존 관계
Kernel Rust abstractionNova GPU memory·interrupt foundationGSP firmware·message·engine supportnova-drm·vGPU manager external APIKUnit·CTS·VFIO continuous integration

공통 Rust API에서 driver consumer와 CI까지 이어집니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 .. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
2
3 =========
4 Task List
5 =========
6
7 Tasks may have the following fields:
8
9 - ``Complexity``: Describes the required familiarity with Rust and / or the
10 corresponding kernel APIs or subsystems. There are four different complexities,
11 ``Beginner``, ``Intermediate``, ``Advanced`` and ``Expert``.
12 - ``Reference``: References to other tasks.
13 - ``Link``: Links to external resources.
14 - ``Contact``: The person that can be contacted for further information about
15 the task.
16
17 A task might have `[ABCD]` code after its name. This code can be used to grep
18 into the code for `TODO` entries related to it.
19
20 Enablement (Rust)
21 =================
22
23 Tasks that are not directly related to nova-core, but are preconditions in terms
24 of required APIs.
25
26 FromPrimitive API [FPRI]
27 ------------------------
28
29 Sometimes the need arises to convert a number to a value of an enum or a
30 structure.
31
32 A good example from nova-core would be the ``Chipset`` enum type, which defines
33 the value ``AD102``. When probing the GPU the value ``0x192`` can be read from a
34 certain register indication the chipset AD102. Hence, the enum value ``AD102``
35 should be derived from the number ``0x192``. Currently, nova-core uses a custom
36 implementation (``Chipset::from_u32`` for this.
37
38 Instead, it would be desirable to have something like the ``FromPrimitive``
39 trait [1] from the num crate.
40
41 Having this generalization also helps with implementing a generic macro that
42 automatically generates the corresponding mappings between a value and a number.
43
44 | Complexity: Beginner
45 | Link: https://docs.rs/num/latest/num/trait.FromPrimitive.html
46
47 Conversion from byte slices for types implementing FromBytes [TRSM]
48 -------------------------------------------------------------------
49
50 We retrieve several structures from byte streams coming from the BIOS or loaded
51 firmware. At the moment converting the bytes slice into the proper type require
52 an inelegant `unsafe` operation; this will go away once `FromBytes` implements
53 a proper `from_bytes` method.
54
55 | Complexity: Beginner
56
57 CoherentAllocation improvements [COHA]
58 --------------------------------------
59
60 `CoherentAllocation` needs a safe way to write into the allocation, and to
61 obtain slices within the allocation.
62
63 | Complexity: Beginner
64 | Contact: Abdiel Janulgue
65
66 Generic register abstraction [REGA]
67 -----------------------------------
68
69 Work out how register constants and structures can be automatically generated
70 through generalized macros.
71
72 Example:
73
74 .. code-block:: rust
75
76 register!(BOOT0, 0x0, u32, pci::Bar<SIZE>, Fields [
77 MINOR_REVISION(3:0, RO),
78 MAJOR_REVISION(7:4, RO),
79 REVISION(7:0, RO), // Virtual register combining major and minor rev.
80 ])
81
82 This could expand to something like:
83
84 .. code-block:: rust
85
86 const BOOT0_OFFSET: usize = 0x00000000;
87 const BOOT0_MINOR_REVISION_SHIFT: u8 = 0;
88 const BOOT0_MINOR_REVISION_MASK: u32 = 0x0000000f;
89 const BOOT0_MAJOR_REVISION_SHIFT: u8 = 4;
90 const BOOT0_MAJOR_REVISION_MASK: u32 = 0x000000f0;
91 const BOOT0_REVISION_SHIFT: u8 = BOOT0_MINOR_REVISION_SHIFT;
92 const BOOT0_REVISION_MASK: u32 = BOOT0_MINOR_REVISION_MASK | BOOT0_MAJOR_REVISION_MASK;
93
94 struct Boot0(u32);
95
96 impl Boot0 {
97 #[inline]
98 fn read(bar: &RevocableGuard<'_, pci::Bar<SIZE>>) -> Self {
99 Self(bar.readl(BOOT0_OFFSET))
100 }
101
102 #[inline]
103 fn minor_revision(&self) -> u32 {
104 (self.0 & BOOT0_MINOR_REVISION_MASK) >> BOOT0_MINOR_REVISION_SHIFT
105 }
106
107 #[inline]
108 fn major_revision(&self) -> u32 {
109 (self.0 & BOOT0_MAJOR_REVISION_MASK) >> BOOT0_MAJOR_REVISION_SHIFT
110 }
111
112 #[inline]
113 fn revision(&self) -> u32 {
114 (self.0 & BOOT0_REVISION_MASK) >> BOOT0_REVISION_SHIFT
115 }
116 }
117
118 Usage:
119
120 .. code-block:: rust
121
122 let bar = bar.try_access().ok_or(ENXIO)?;
123
124 let boot0 = Boot0::read(&bar);
125 pr_info!("Revision: {}\n", boot0.revision());
126
127 A work-in-progress implementation currently resides in
128 `drivers/gpu/nova-core/regs/macros.rs` and is used in nova-core. It would be
129 nice to improve it (possibly using proc macros) and move it to the `kernel`
130 crate so it can be used by other components as well.
131
132 Features desired before this happens:
133
134 * Make I/O optional I/O (for field values that are not registers),
135 * Support other sizes than `u32`,
136 * Allow visibility control for registers and individual fields,
137 * Use Rust slice syntax to express fields ranges.
138
139 | Complexity: Advanced
140 | Contact: Alexandre Courbot
141
142 Numerical operations [NUMM]
143 ---------------------------
144
145 Nova uses integer operations that are not part of the standard library (or not
146 implemented in an optimized way for the kernel). These include:
147
148 - The "Find Last Set Bit" (`fls` function of the C part of the kernel)
149 operation.
150
151 A `num` core kernel module is being designed to provide these operations.
152
153 | Complexity: Intermediate
154 | Contact: Alexandre Courbot
155
156 Delay / Sleep abstractions [DLAY]
157 ---------------------------------
158
159 Rust abstractions for the kernel's delay() and sleep() functions.
160
161 FUJITA Tomonori plans to work on abstractions for read_poll_timeout_atomic()
162 (and friends) [1].
163
164 | Complexity: Beginner
165 | Link: https://lore.kernel.org/netdev/[email protected]/ [1]
166
167 IRQ abstractions
168 ----------------
169
170 Rust abstractions for IRQ handling.
171
172 There is active ongoing work from Daniel Almeida [1] for the "core" abstractions
173 to request IRQs.
174
175 Besides optional review and testing work, the required ``pci::Device`` code
176 around those core abstractions needs to be worked out.
177
178 | Complexity: Intermediate
179 | Link: https://lore.kernel.org/lkml/[email protected]/ [1]
180 | Contact: Daniel Almeida
181
182 Page abstraction for foreign pages
183 ----------------------------------
184
185 Rust abstractions for pages not created by the Rust page abstraction without
186 direct ownership.
187
188 There is active onging work from Abdiel Janulgue [1] and Lina [2].
189
190 | Complexity: Advanced
191 | Link: https://lore.kernel.org/linux-mm/[email protected]/ [1]
192 | Link: https://lore.kernel.org/rust-for-linux/[email protected]/ [2]
193
194 Scatterlist / sg_table abstractions
195 -----------------------------------
196
197 Rust abstractions for scatterlist / sg_table.
198
199 There is preceding work from Abdiel Janulgue, which hasn't made it to the
200 mailing list yet.
201
202 | Complexity: Intermediate
203 | Contact: Abdiel Janulgue
204
205 PCI MISC APIs
206 -------------
207
208 Extend the existing PCI device / driver abstractions by SR-IOV, config space,
209 capability, MSI API abstractions.
210
211 | Complexity: Beginner
212
213 XArray bindings [XARR]
214 ----------------------
215
216 We need bindings for `xa_alloc`/`xa_alloc_cyclic` in order to generate the
217 auxiliary device IDs.
218
219 | Complexity: Intermediate
220
221 Debugfs abstractions
222 --------------------
223
224 Rust abstraction for debugfs APIs.
225
226 | Reference: Export GSP log buffers
227 | Complexity: Intermediate
228
229 GPU (general)
230 =============
231
232 Initial Devinit support
233 -----------------------
234
235 Implement BIOS Device Initialization, i.e. memory sizing, waiting, PLL
236 configuration.
237
238 | Contact: Dave Airlie
239 | Complexity: Beginner
240
241 MMU / PT management
242 -------------------
243
244 Work out the architecture for MMU / page table management.
245
246 We need to consider that nova-drm will need rather fine-grained control,
247 especially in terms of locking, in order to be able to implement asynchronous
248 Vulkan queues.
249
250 While generally sharing the corresponding code is desirable, it needs to be
251 evaluated how (and if at all) sharing the corresponding code is expedient.
252
253 | Complexity: Expert
254
255 VRAM memory allocator
256 ---------------------
257
258 Investigate options for a VRAM memory allocator.
259
260 Some possible options:
261 - Rust abstractions for
262 - RB tree (interval tree) / drm_mm
263 - maple_tree
264 - native Rust collections
265
266 | Complexity: Advanced
267
268 Instance Memory
269 ---------------
270
271 Implement support for instmem (bar2) used to store page tables.
272
273 | Complexity: Intermediate
274 | Contact: Dave Airlie
275
276 GPU System Processor (GSP)
277 ==========================
278
279 Export GSP log buffers
280 ----------------------
281
282 Recent patches from Timur Tabi [1] added support to expose GSP-RM log buffers
283 (even after failure to probe the driver) through debugfs.
284
285 This is also an interesting feature for nova-core, especially in the early days.
286
287 | Link: https://lore.kernel.org/nouveau/[email protected]/ [1]
288 | Reference: Debugfs abstractions
289 | Complexity: Intermediate
290
291 GSP firmware abstraction
292 ------------------------
293
294 The GSP-RM firmware API is unstable and may incompatibly change from version to
295 version, in terms of data structures and semantics.
296
297 This problem is one of the big motivations for using Rust for nova-core, since
298 it turns out that Rust's procedural macro feature provides a rather elegant way
299 to address this issue:
300
301 1. generate Rust structures from the C headers in a separate namespace per version
302 2. build abstraction structures (within a generic namespace) that implement the
303 firmware interfaces; annotate the differences in implementation with version
304 identifiers
305 3. use a procedural macro to generate the actual per version implementation out
306 of this abstraction
307 4. instantiate the correct version type one on runtime (can be sure that all
308 have the same interface because it's defined by a common trait)
309
310 There is a PoC implementation of this pattern, in the context of the nova-core
311 PoC driver.
312
313 This task aims at refining the feature and ideally generalize it, to be usable
314 by other drivers as well.
315
316 | Complexity: Expert
317
318 GSP message queue
319 -----------------
320
321 Implement low level GSP message queue (command, status) for communication
322 between the kernel driver and GSP.
323
324 | Complexity: Advanced
325 | Contact: Dave Airlie
326
327 Bootstrap GSP
328 -------------
329
330 Call the boot firmware to boot the GSP processor; execute initial control
331 messages.
332
333 | Complexity: Intermediate
334 | Contact: Dave Airlie
335
336 Client / Device APIs
337 --------------------
338
339 Implement the GSP message interface for client / device allocation and the
340 corresponding client and device allocation APIs.
341
342 | Complexity: Intermediate
343 | Contact: Dave Airlie
344
345 Bar PDE handling
346 ----------------
347
348 Synchronize page table handling for BARs between the kernel driver and GSP.
349
350 | Complexity: Beginner
351 | Contact: Dave Airlie
352
353 FIFO engine
354 -----------
355
356 Implement support for the FIFO engine, i.e. the corresponding GSP message
357 interface and provide an API for chid allocation and channel handling.
358
359 | Complexity: Advanced
360 | Contact: Dave Airlie
361
362 GR engine
363 ---------
364
365 Implement support for the graphics engine, i.e. the corresponding GSP message
366 interface and provide an API for (golden) context creation and promotion.
367
368 | Complexity: Advanced
369 | Contact: Dave Airlie
370
371 CE engine
372 ---------
373
374 Implement support for the copy engine, i.e. the corresponding GSP message
375 interface.
376
377 | Complexity: Intermediate
378 | Contact: Dave Airlie
379
380 VFN IRQ controller
381 ------------------
382
383 Support for the VFN interrupt controller.
384
385 | Complexity: Intermediate
386 | Contact: Dave Airlie
387
388 External APIs
389 =============
390
391 nova-core base API
392 ------------------
393
394 Work out the common pieces of the API to connect 2nd level drivers, i.e. vGPU
395 manager and nova-drm.
396
397 | Complexity: Advanced
398
399 vGPU manager API
400 ----------------
401
402 Work out the API parts required by the vGPU manager, which are not covered by
403 the base API.
404
405 | Complexity: Advanced
406
407 nova-core C API
408 ---------------
409
410 Implement a C wrapper for the APIs required by the vGPU manager driver.
411
412 | Complexity: Intermediate
413
414 Testing
415 =======
416
417 CI pipeline
418 -----------
419
420 Investigate option for continuous integration testing.
421
422 This can go from as simple as running KUnit tests over running (graphics) CTS to
423 booting up (multiple) guest VMs to test VFIO use-cases.
424
425 It might also be worth to consider the introduction of a new test suite directly
426 sitting on top of the uAPI for more targeted testing and debugging. There may be
427 options for collaboration / shared code with the Mesa project.
428
429 | Complexity: Advanced
430

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

Task list 형식

1-19

이 문서는 `nova-core` 개발에 필요한 task list입니다. 원문 SPDX 라이선스는 `(GPL-2.0+ OR MIT)`입니다.

각 task의 `Complexity`는 필요한 Rust 지식 또는 관련 kernel API·subsystem 친숙도를 나타냅니다. 단계는 `Beginner`, `Intermediate`, `Advanced`, `Expert` 네 가지입니다.

`Reference`는 다른 task를 가리키고, `Link`는 외부 자료, `Contact`는 추가 정보를 문의할 담당자를 나타냅니다.

Task 이름 뒤의 `[ABCD]` code는 source tree에서 해당 task와 관련된 `TODO` entry를 grep할 때 사용하는 식별자입니다.

Task metadata
Field의미
ComplexityBeginner·Intermediate·Advanced·Expert
Reference의존하거나 연관된 다른 task
LinkMailing list·documentation 등 외부 자료
Contact추가 정보를 제공할 담당자
[ABCD]Code의 TODO를 찾는 grep marker

각 TODO entry에서 사용하는 공통 field입니다.

Task 선택 절차
Task 제목과 [ABCD] marker 확인Complexity와 관련 subsystem 파악Reference로 선행 task 확인Link의 진행 중 patch·API 검토필요하면 Contact와 조율

선행 조건과 난이도를 함께 확인합니다.

.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)

=========
Task List
=========

Tasks may have the following fields:

- ``Complexity``: Describes the required familiarity with Rust and / or the
  corresponding kernel APIs or subsystems. There are four different complexities,
  ``Beginner``, ``Intermediate``, ``Advanced`` and ``Expert``.
- ``Reference``: References to other tasks.
- ``Link``: Links to external resources.
- ``Contact``: The person that can be contacted for further information about
  the task.

A task might have `[ABCD]` code after its name. This code can be used to grep
into the code for `TODO` entries related to it.

Rust enablement: conversion·allocation·register

20-141

`Enablement (Rust)`는 `nova-core` 자체 기능은 아니지만 필요한 kernel Rust API를 마련하는 선행 작업입니다.

`FromPrimitive API [FPRI]`는 number를 enum 또는 structure 값으로 변환하는 일반 API를 요구합니다. 예를 들어 GPU probe에서 register 값 `0x192`를 읽으면 `Chipset::AD102`를 얻어야 합니다. 현재 `Chipset::from_u32`라는 자체 구현을 사용하지만, num crate의 `FromPrimitive` trait 같은 일반화가 바람직합니다. 이 일반화는 number와 value 사이 mapping을 자동 생성하는 generic macro에도 도움이 됩니다. 난이도는 Beginner입니다.

`Conversion from byte slices for types implementing FromBytes [TRSM]`는 BIOS나 loaded firmware의 byte stream에서 structure를 복원하는 문제입니다. 현재 byte slice를 올바른 type으로 바꾸려면 세련되지 않은 `unsafe` operation이 필요합니다. `FromBytes`가 적절한 `from_bytes` method를 제공하면 이를 제거할 수 있습니다. 난이도는 Beginner입니다.

`CoherentAllocation improvements [COHA]`는 allocation에 안전하게 write하고 allocation 내부 slice를 얻는 방법을 `CoherentAllocation`에 추가하는 task입니다. 난이도는 Beginner이고 contact는 Abdiel Janulgue입니다.

`Generic register abstraction [REGA]`는 generalized macro로 register constant와 structure를 자동 생성하는 방법을 정립합니다. 원문의 `register!(BOOT0, ...)` 입력은 offset, backing type, PCI BAR, read-only bit field를 선언하고 `BOOT0_OFFSET`, shift·mask constant, `Boot0(u32)`와 accessor method로 확장됩니다.

사용 예제는 revocable PCI BAR guard를 얻어 `Boot0::read(&bar)`로 register를 읽고 `boot0.revision()`을 출력합니다. Work-in-progress 구현은 `drivers/gpu/nova-core/regs/macros.rs`에 있으며 현재 nova-core가 사용합니다.

이 구현을 개선하고 가능하면 proc macro를 사용하여 다른 component도 쓸 수 있도록 `kernel` crate로 옮기는 것이 목표입니다. 이동 전 필요한 기능은 register가 아닌 field value를 위한 optional I/O, `u32` 외 크기, register·개별 field visibility control, field range를 표현하는 Rust slice syntax입니다. 난이도는 Advanced, contact는 Alexandre Courbot입니다.

초기 Rust enablement
Task필요 기능난이도
FPRINumber → enum/structure FromPrimitive 변환Beginner
TRSMFromBytes type의 안전한 byte-slice 변환Beginner
COHACoherentAllocation safe write·sliceBeginner
REGAGeneric register macro와 typed accessorAdvanced

Nova-core가 현재 우회 구현으로 해결하는 선행 API입니다.

Generic register macro 확장
register!에 offset·type·BAR·field range 선언Offset·SHIFT·MASK constant 생성Boot0 newtype 생성BAR read method와 field accessor 생성Rust slice syntax·visibility·다중 크기 지원 후 kernel crate 이동

선언에서 type-safe register API가 생성되는 과정입니다.

REGA 추가 요구사항
요구사항설명
Optional I/ORegister가 아닌 field value도 지원
Data sizeu32 외 크기 지원
VisibilityRegister와 field별 공개 범위 제어
Range syntaxRust slice syntax로 bit range 표현
Implementationdrivers/gpu/nova-core/regs/macros.rs 개선

공용 kernel abstraction이 되기 전에 필요한 기능입니다.

Enablement (Rust)
=================

Tasks that are not directly related to nova-core, but are preconditions in terms
of required APIs.

FromPrimitive API [FPRI]
------------------------

Sometimes the need arises to convert a number to a value of an enum or a
structure.

A good example from nova-core would be the ``Chipset`` enum type, which defines
the value ``AD102``. When probing the GPU the value ``0x192`` can be read from a
certain register indication the chipset AD102. Hence, the enum value ``AD102``
should be derived from the number ``0x192``. Currently, nova-core uses a custom
implementation (``Chipset::from_u32`` for this.

Instead, it would be desirable to have something like the ``FromPrimitive``
trait [1] from the num crate.

Having this generalization also helps with implementing a generic macro that
automatically generates the corresponding mappings between a value and a number.

| Complexity: Beginner
| Link: https://docs.rs/num/latest/num/trait.FromPrimitive.html

Conversion from byte slices for types implementing FromBytes [TRSM]
-------------------------------------------------------------------

We retrieve several structures from byte streams coming from the BIOS or loaded
firmware. At the moment converting the bytes slice into the proper type require
an inelegant `unsafe` operation; this will go away once `FromBytes` implements
a proper `from_bytes` method.

| Complexity: Beginner

CoherentAllocation improvements [COHA]
--------------------------------------

`CoherentAllocation` needs a safe way to write into the allocation, and to
obtain slices within the allocation.

| Complexity: Beginner
| Contact: Abdiel Janulgue

Generic register abstraction [REGA]
-----------------------------------

Work out how register constants and structures can be automatically generated
through generalized macros.

Example:

.. code-block:: rust

        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.
        ])

This could expand to something like:

.. code-block:: rust

        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
           }
        }

Usage:

.. code-block:: rust

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

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

A work-in-progress implementation currently resides in
`drivers/gpu/nova-core/regs/macros.rs` and is used in nova-core. It would be
nice to improve it (possibly using proc macros) and move it to the `kernel`
crate so it can be used by other components as well.

Features desired before this happens:

* Make I/O optional I/O (for field values that are not registers),
* Support other sizes than `u32`,
* Allow visibility control for registers and individual fields,
* Use Rust slice syntax to express fields ranges.

| Complexity: Advanced
| Contact: Alexandre Courbot

Rust enablement: kernel subsystem API

142-228

`Numerical operations [NUMM]`은 standard library에 없거나 kernel용 최적화 구현이 없는 integer operation을 제공합니다. 현재 예는 C kernel의 `fls`에 해당하는 Find Last Set Bit입니다. 이 연산을 제공할 `num` core kernel module이 설계 중입니다. 난이도는 Intermediate, contact는 Alexandre Courbot입니다.

`Delay / Sleep abstractions [DLAY]`는 kernel의 `delay()`와 `sleep()` function을 위한 Rust abstraction입니다. FUJITA Tomonori가 `read_poll_timeout_atomic()` 계열 abstraction을 작업할 계획입니다. 난이도는 Beginner입니다.

`IRQ abstractions`는 IRQ handling용 Rust API입니다. Daniel Almeida가 IRQ를 request하는 core abstraction을 작업 중입니다. 선택적인 review·test 외에 이 core API 주변의 `pci::Device` code를 설계해야 합니다. 난이도는 Intermediate이며 Daniel Almeida가 contact입니다.

`Page abstraction for foreign pages`는 Rust page abstraction이 생성하지 않았고 직접 ownership하지 않는 page를 다루는 Rust API입니다. Abdiel Janulgue와 Lina가 진행 중이며 난이도는 Advanced입니다.

`Scatterlist / sg_table abstractions`는 scatterlist와 `sg_table`의 Rust abstraction입니다. Abdiel Janulgue의 선행 작업이 있지만 아직 mailing list에 올라오지 않았습니다. 난이도는 Intermediate입니다.

`PCI MISC APIs`는 기존 PCI device/driver abstraction에 SR-IOV, config space, capability, MSI API를 추가합니다. 난이도는 Beginner입니다.

`XArray bindings [XARR]`은 auxiliary device ID를 생성하기 위해 `xa_alloc`과 `xa_alloc_cyclic` binding을 요구합니다. 난이도는 Intermediate입니다.

`Debugfs abstractions`는 debugfs API의 Rust abstraction이며 `Export GSP log buffers` task의 선행 조건입니다. 난이도는 Intermediate입니다.

Kernel Rust subsystem task
Task범위난이도
NUMMfls 등 integer operationIntermediate
DLAYdelay·sleep·read_poll_timeout_atomicBeginner
IRQCore IRQ request + pci::Device integrationIntermediate
Foreign pages직접 소유하지 않는 page abstractionAdvanced
scatterlist/sg_tableDMA scatter-gather abstractionIntermediate
PCI MISCSR-IOV·config·capability·MSIBeginner
XARRxa_alloc·xa_alloc_cyclic bindingIntermediate
DebugfsRust debugfs APIIntermediate

Nova-core 밖에서 마련해야 할 공통 API입니다.

선행 API 의존 관계
Core IRQ abstraction → pci::Device integrationForeign page·scatterlist abstraction → DMA memory handlingPCI MISC → SR-IOV·MSI 지원XArray binding → auxiliary device ID allocationDebugfs abstraction → GSP log export

Nova 기능이 공통 Rust abstraction에 의존하는 예입니다.

외부 진행 자료
원문 줄URL
45https://docs.rs/num/latest/num/trait.FromPrimitive.html
165https://lore.kernel.org/netdev/[email protected]/
179https://lore.kernel.org/lkml/[email protected]/
191https://lore.kernel.org/linux-mm/[email protected]/
192https://lore.kernel.org/rust-for-linux/[email protected]/

원문 line과 URL을 그대로 보존한 관련 작업입니다.

Numerical operations [NUMM]
---------------------------

Nova uses integer operations that are not part of the standard library (or not
implemented in an optimized way for the kernel). These include:

- The "Find Last Set Bit" (`fls` function of the C part of the kernel)
  operation.

A `num` core kernel module is being designed to provide these operations.

| Complexity: Intermediate
| Contact: Alexandre Courbot

Delay / Sleep abstractions [DLAY]
---------------------------------

Rust abstractions for the kernel's delay() and sleep() functions.

FUJITA Tomonori plans to work on abstractions for read_poll_timeout_atomic()
(and friends) [1].

| Complexity: Beginner
| Link: https://lore.kernel.org/netdev/[email protected]/ [1]

IRQ abstractions
----------------

Rust abstractions for IRQ handling.

There is active ongoing work from Daniel Almeida [1] for the "core" abstractions
to request IRQs.

Besides optional review and testing work, the required ``pci::Device`` code
around those core abstractions needs to be worked out.

| Complexity: Intermediate
| Link: https://lore.kernel.org/lkml/[email protected]/ [1]
| Contact: Daniel Almeida

Page abstraction for foreign pages
----------------------------------

Rust abstractions for pages not created by the Rust page abstraction without
direct ownership.

There is active onging work from Abdiel Janulgue [1] and Lina [2].

| Complexity: Advanced
| Link: https://lore.kernel.org/linux-mm/[email protected]/ [1]
| Link: https://lore.kernel.org/rust-for-linux/[email protected]/ [2]

Scatterlist / sg_table abstractions
-----------------------------------

Rust abstractions for scatterlist / sg_table.

There is preceding work from Abdiel Janulgue, which hasn't made it to the
mailing list yet.

| Complexity: Intermediate
| Contact: Abdiel Janulgue

PCI MISC APIs
-------------

Extend the existing PCI device / driver abstractions by SR-IOV, config space,
capability, MSI API abstractions.

| Complexity: Beginner

XArray bindings [XARR]
----------------------

We need bindings for `xa_alloc`/`xa_alloc_cyclic` in order to generate the
auxiliary device IDs.

| Complexity: Intermediate

Debugfs abstractions
--------------------

Rust abstraction for debugfs APIs.

| Reference: Export GSP log buffers
| Complexity: Intermediate

GPU 일반 기능

229-275

`Initial Devinit support`는 BIOS Device Initialization을 구현하는 task입니다. Memory sizing·waiting·PLL configuration이 포함됩니다. 난이도는 Beginner, contact는 Dave Airlie입니다.

`MMU / PT management`는 MMU와 page table 관리 architecture를 정하는 Expert task입니다. 특히 `nova-drm`이 asynchronous Vulkan queue를 구현하려면 locking을 포함한 매우 세밀한 control이 필요합니다. 관련 code를 공유하는 편이 일반적으로 바람직하지만 실제로 어떻게, 또는 공유 자체가 유리한지 평가해야 합니다.

`VRAM memory allocator`는 allocator 선택지를 조사하는 Advanced task입니다. 후보는 RB tree(interval tree)·`drm_mm`의 Rust abstraction, `maple_tree`, native Rust collection입니다.

`Instance Memory`는 page table을 저장하는 `instmem (bar2)` 지원을 구현합니다. 난이도는 Intermediate이고 contact는 Dave Airlie입니다.

GPU general task
Task핵심난이도
Initial DevinitMemory sizing·wait·PLL configurationBeginner
MMU/PTFine-grained locking과 async Vulkan queueExpert
VRAM allocatordrm_mm·maple_tree·Rust collection 검토Advanced
Instance Memorybar2의 page-table storageIntermediate

초기화·address space·VRAM 기반 기능입니다.

GPU memory enablement
BIOS devinit으로 memory size·PLL 설정MMU/page-table architecture와 locking 결정VRAM allocator backend 선택bar2 instance memory에 page table 저장nova-drm의 asynchronous queue 제어 제공

초기화 뒤 address space와 allocator를 마련하는 순서입니다.

GPU (general)
=============

Initial Devinit support
-----------------------

Implement BIOS Device Initialization, i.e. memory sizing, waiting, PLL
configuration.

| Contact: Dave Airlie
| Complexity: Beginner

MMU / PT management
-------------------

Work out the architecture for MMU / page table management.

We need to consider that nova-drm will need rather fine-grained control,
especially in terms of locking, in order to be able to implement asynchronous
Vulkan queues.

While generally sharing the corresponding code is desirable, it needs to be
evaluated how (and if at all) sharing the corresponding code is expedient.

| Complexity: Expert

VRAM memory allocator
---------------------

Investigate options for a VRAM memory allocator.

Some possible options:
  - Rust abstractions for
    - RB tree (interval tree) / drm_mm
    - maple_tree
  - native Rust collections

| Complexity: Advanced

Instance Memory
---------------

Implement support for instmem (bar2) used to store page tables.

| Complexity: Intermediate
| Contact: Dave Airlie

GPU System Processor task

276-387

`Export GSP log buffers`는 GSP-RM log buffer를 driver probe 실패 뒤에도 debugfs로 공개하는 기능입니다. Timur Tabi의 최근 patch가 이를 구현했으며 nova-core 초기 개발에도 유용합니다. `Debugfs abstractions`가 선행 조건이고 난이도는 Intermediate입니다.

`GSP firmware abstraction`은 version마다 data structure와 semantic이 비호환으로 바뀔 수 있는 불안정한 GSP-RM firmware API를 추상화하는 Expert task입니다. Rust procedural macro가 이 문제를 해결하기에 적합하다는 점이 nova-core에서 Rust를 사용하는 큰 동기입니다.

제안 pattern은 네 단계입니다. 먼저 C header에서 version별 namespace의 Rust structure를 생성합니다. 다음으로 generic namespace에서 firmware interface를 구현하는 abstraction structure를 만들고 implementation 차이에 version identifier를 붙입니다. Procedural macro가 이 abstraction으로 실제 version별 implementation을 생성하고, runtime에는 공통 trait 덕분에 같은 interface가 보장되는 올바른 version type을 instantiate합니다.

Nova-core PoC driver에 이 pattern의 PoC가 있습니다. Task 목표는 기능을 다듬고 다른 driver도 사용할 수 있도록 일반화하는 것입니다.

`GSP message queue`는 kernel driver와 GSP 사이 command·status communication을 위한 low-level queue를 구현합니다. 난이도는 Advanced입니다. `Bootstrap GSP`는 boot firmware를 호출해 GSP processor를 boot하고 초기 control message를 실행하는 Intermediate task입니다.

`Client / Device APIs`는 client/device allocation용 GSP message interface와 해당 allocation API를 구현합니다. `Bar PDE handling`은 kernel driver와 GSP 사이 BAR page-table 처리를 동기화합니다. 각각 Intermediate와 Beginner입니다.

`FIFO engine`은 GSP message interface와 `chid` allocation·channel handling API를 구현하는 Advanced task입니다. `GR engine`은 graphics engine의 GSP interface와 golden context 생성·promotion API를 구현하는 Advanced task입니다.

`CE engine`은 copy engine용 GSP message interface를 구현하는 Intermediate task이고, `VFN IRQ controller`는 VFN interrupt controller 지원을 추가하는 Intermediate task입니다. 이 GSP 실행 기능들의 contact는 Dave Airlie입니다.

GSP task
Task핵심난이도
Export logsProbe 실패 뒤에도 GSP-RM log를 debugfs에 노출Intermediate
Firmware abstractionVersion별 API를 procedural macro로 통합Expert
Message queueKernel↔GSP command·statusAdvanced
BootstrapBoot firmware와 초기 control messageIntermediate
Client/DeviceAllocation message와 APIIntermediate
BAR PDEDriver↔GSP page-table 동기화Beginner
FIFOchid allocation·channel handlingAdvanced
GRGolden context 생성·promotionAdvanced
CECopy engine message interfaceIntermediate
VFN IRQVFN interrupt controllerIntermediate

Firmware boot에서 engine API까지의 구현 목록입니다.

GSP 기능 구현 순서
Version-independent firmware abstractionLow-level command·status message queueBoot firmware로 GSP bootstrapClient·device allocation과 BAR PDE 동기화FIFO·GR·CE engine APIVFN IRQ와 debugfs log export

Communication 기반부터 engine API로 확장합니다.

Firmware version macro pattern
단계처리
1C header → version별 namespace의 Rust structure
2Generic abstraction + version identifier annotation
3Procedural macro → version별 implementation
4Runtime에 공통 trait의 올바른 version type instantiate

원문의 네 단계 생성 전략입니다.

GPU System Processor (GSP)
==========================

Export GSP log buffers
----------------------

Recent patches from Timur Tabi [1] added support to expose GSP-RM log buffers
(even after failure to probe the driver) through debugfs.

This is also an interesting feature for nova-core, especially in the early days.

| Link: https://lore.kernel.org/nouveau/[email protected]/ [1]
| Reference: Debugfs abstractions
| Complexity: Intermediate

GSP firmware abstraction
------------------------

The GSP-RM firmware API is unstable and may incompatibly change from version to
version, in terms of data structures and semantics.

This problem is one of the big motivations for using Rust for nova-core, since
it turns out that Rust's procedural macro feature provides a rather elegant way
to address this issue:

1. generate Rust structures from the C headers in a separate namespace per version
2. build abstraction structures (within a generic namespace) that implement the
   firmware interfaces; annotate the differences in implementation with version
   identifiers
3. use a procedural macro to generate the actual per version implementation out
   of this abstraction
4. instantiate the correct version type one on runtime (can be sure that all
   have the same interface because it's defined by a common trait)

There is a PoC implementation of this pattern, in the context of the nova-core
PoC driver.

This task aims at refining the feature and ideally generalize it, to be usable
by other drivers as well.

| Complexity: Expert

GSP message queue
-----------------

Implement low level GSP message queue (command, status) for communication
between the kernel driver and GSP.

| Complexity: Advanced
| Contact: Dave Airlie

Bootstrap GSP
-------------

Call the boot firmware to boot the GSP processor; execute initial control
messages.

| Complexity: Intermediate
| Contact: Dave Airlie

Client / Device APIs
--------------------

Implement the GSP message interface for client / device allocation and the
corresponding client and device allocation APIs.

| Complexity: Intermediate
| Contact: Dave Airlie

Bar PDE handling
----------------

Synchronize page table handling for BARs between the kernel driver and GSP.

| Complexity: Beginner
| Contact: Dave Airlie

FIFO engine
-----------

Implement support for the FIFO engine, i.e. the corresponding GSP message
interface and provide an API for chid allocation and channel handling.

| Complexity: Advanced
| Contact: Dave Airlie

GR engine
---------

Implement support for the graphics engine, i.e. the corresponding GSP message
interface and provide an API for (golden) context creation and promotion.

| Complexity: Advanced
| Contact: Dave Airlie

CE engine
---------

Implement support for the copy engine, i.e. the corresponding GSP message
interface.

| Complexity: Intermediate
| Contact: Dave Airlie

VFN IRQ controller
------------------

Support for the VFN interrupt controller.

| Complexity: Intermediate
| Contact: Dave Airlie

Second-level driver용 외부 API

388-413

`nova-core base API`는 vGPU manager와 `nova-drm` 같은 second-level driver를 연결하는 공통 API 부분을 설계하는 Advanced task입니다.

`vGPU manager API`는 base API가 다루지 않는 vGPU manager 전용 부분을 설계하는 Advanced task입니다.

`nova-core C API`는 vGPU manager driver가 요구하는 API의 C wrapper를 구현하는 Intermediate task입니다.

External API layer
API범위난이도
Base APInova-drm·vGPU manager 공통 연결Advanced
vGPU manager APIBase에 없는 manager 전용 기능Advanced
C APIvGPU manager용 C wrapperIntermediate

공통 Rust core와 소비자별 접점을 분리합니다.

External consumer 연결
GSP firmware implementationnova-core internal abstractionnova-core base APInova-drm 또는 vGPU manager API필요 시 vGPU manager용 C wrapper

Firmware 세부사항을 숨긴 API 계층입니다.

External APIs
=============

nova-core base API
------------------

Work out the common pieces of the API to connect 2nd level drivers, i.e. vGPU
manager and nova-drm.

| Complexity: Advanced

vGPU manager API
----------------

Work out the API parts required by the vGPU manager, which are not covered by
the base API.

| Complexity: Advanced

nova-core C API
---------------

Implement a C wrapper for the APIs required by the vGPU manager driver.

| Complexity: Intermediate

CI와 targeted uAPI test

414-429

`CI pipeline` task는 continuous integration test 선택지를 조사합니다. 난이도는 Advanced입니다.

범위는 단순한 KUnit test 실행부터 graphics CTS, 여러 guest VM boot를 통한 VFIO use-case 검증까지 확장할 수 있습니다.

더 정밀한 test와 debugging을 위해 uAPI 바로 위에 놓이는 새 test suite 도입도 검토할 가치가 있습니다. Mesa project와 협력하거나 code를 공유할 가능성도 있습니다.

CI 수준
수준검증
KUnitKernel 내부 unit test
Graphics CTSGraphics conformance·behavior
Guest VMs복수 VM의 VFIO use-case
Targeted uAPI suiteuAPI 직접 test와 debugging

비용과 coverage가 증가하는 test 선택지입니다.

Nova-core CI 확장
KUnit baselineGraphics CTSuAPI-targeted regression suite복수 guest VM·VFIO scenarioMesa와 test code·infrastructure 협업

작은 unit test에서 통합 virtualization 검증으로 확장합니다.

Testing
=======

CI pipeline
-----------

Investigate option for continuous integration testing.

This can go from as simple as running KUnit tests over running (graphics) CTS to
booting up (multiple) guest VMs to test VFIO use-cases.

It might also be worth to consider the introduction of a new test suite directly
sitting on top of the uAPI for more targeted testing and debugging. There may be
options for collaboration / shared code with the Mesa project.

| Complexity: Advanced