FromPrimitive API [FPRI]¶

Sometimes the need arises to convert a number to a value of anenumor astructure.

A good example from nova-core would be theChipsetenumtype, which definesthe valueAD102. When probing the GPU the value0x192 can be read from acertain register indication the chipset AD102. Hence, theenumvalueAD102should be derived from the number0x192. Currently, nova-core uses a customimplementation (Chipset::from_u32 for this.

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

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

FromPrimitive support has been worked on in the past, but hasn’t been followedsince then [1].

There also have been considerations of ToPrimitive [2].

Generic register abstraction [REGA]¶

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

Example:

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:

constBOOT0_OFFSET:usize=0x00000000;constBOOT0_MINOR_REVISION_SHIFT:u8=0;constBOOT0_MINOR_REVISION_MASK:u32=0x0000000f;constBOOT0_MAJOR_REVISION_SHIFT:u8=4;constBOOT0_MAJOR_REVISION_MASK:u32=0x000000f0;constBOOT0_REVISION_SHIFT:u8=BOOT0_MINOR_REVISION_SHIFT;constBOOT0_REVISION_MASK:u32=BOOT0_MINOR_REVISION_MASK|BOOT0_MAJOR_REVISION_MASK;structBoot0(u32);implBoot0{#[inline]fnread(bar:&RevocableGuard<'_,pci::Bar<SIZE>>)->Self{Self(bar.readl(BOOT0_OFFSET))}#[inline]fnminor_revision(&self)->u32{(self.0&BOOT0_MINOR_REVISION_MASK)>>BOOT0_MINOR_REVISION_SHIFT}#[inline]fnmajor_revision(&self)->u32{(self.0&BOOT0_MAJOR_REVISION_MASK)>>BOOT0_MAJOR_REVISION_SHIFT}#[inline]fnrevision(&self)->u32{(self.0&BOOT0_REVISION_MASK)>>BOOT0_REVISION_SHIFT}}

Usage:

letbar=bar.try_access().ok_or(ENXIO)?;letboot0=Boot0::read(&bar);pr_info!("Revision: {}\n",boot0.revision());

A work-in-progress implementation currently resides indrivers/gpu/nova-core/regs/macros.rs and is used in nova-core. It would benice to improve it (possibly using proc macros) and move it to thekernelcrate 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 thanu32,

• Allow visibility control for registers and individual fields,

• Use Rust slice syntax to express fields ranges.

Numerical operations [NUMM]¶

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

• The “Find Last Set Bit” (fls function of the C part of the kernel)operation.

Anum core kernel module is being designed to provide these operations.

Page abstraction for foreign pages¶

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

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

PCI MISC APIs¶

Extend the existing PCI device / driver abstractions by SR-IOV, capability, MSIAPI abstractions.

SR-IOV [1] is work in progress.

Initial Devinit support¶

Implement BIOS Device Initialization, i.e. memory sizing, waiting, PLLconfiguration.

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 asynchronousVulkan queues.

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

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

There is work in progress for using drm_buddy [1].

Instance Memory¶

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

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.

GSP firmware abstraction¶

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

This problem is one of the big motivations for using Rust for nova-core, sinceit turns out that Rust’s procedural macro feature provides a rather elegant wayto 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 thefirmware interfaces; annotate the differences in implementation with versionidentifiers

3. use a procedural macro to generate the actual per version implementation outof this abstraction

4. instantiate the correct version type one on runtime (can be sure that allhave 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-corePoC driver.

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

GSP message queue¶

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

Bootstrap GSP¶

Call the boot firmware to boot the GSP processor; execute initial controlmessages.

Client / Device APIs¶

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

Bar PDE handling¶

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

FIFO engine¶

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

GR engine¶

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

CE engine¶

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

VFN IRQ controller¶

Support for the VFN interrupt controller.

nova-core base API¶

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

vGPU manager API¶

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

nova-core C API¶

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

CI pipeline¶

Investigate option for continuous integration testing.

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

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