Re: [PATCH 01/13] gpu: nova-core: vgpu: add post-GSP-boot vGPU initialization

Hi Zhi,

On Sat Sep 5, 2026 at 5:11 PM JST, Zhi Wang wrote:

GSP-RM does not expose the parameters needed to divide resources among
vGPU instances until GSP_INIT completes. Before this point VgpuManager
only knows whether vGPU mode is enabled, so it cannot provide the engine
topology, VMMU alignment, or channel capacity required by instance
management.

Decode the VMMU segment size and ordered FIFO engine table from the typed
GSP_INIT NVKV response. Retain only host-driven engines while preserving
hardware FIFO order. After a successful GSP_INIT, initialize the manager
with these values and the 2048-channel capacity, but retain them only when
vGPU mode is enabled.

Move VgpuManager into Gpu and let it borrow the pinned ChannelIdPool.
Create that pool with the same channel capacity, order the Gpu fields so
the manager is dropped before the memory manager, GSP resources, and its
channel pool, and pass it separately to GSP boot so unload resources do
not retain a manager reference. Keep a copy of the detected mode in the
GPU-owned GSP runtime data instead of passing it through the HAL calls.

The commit log reads like this patch tries to group several things
together. The diff below makes it even more clear:

<...>

 drivers/gpu/nova-core/vgpu.rs            |  91 ---------------
 drivers/gpu/nova-core/vgpu/mod.rs        | 139 +++++++++++++++++++++++

This moves code around while adding features to the moved block, making
it very difficult to understand what happens looking at the diff.
Typically when you need to do what you will want to split into two
or more patches: one that is purely mechanical and moves the original code to
its destination, ideally without any change, and then the changes you
want to apply, one per patch.

In this case though there is probably no need for the move at all: even
if you plan on adding sub-modules to `vgpu`, the main module can stay in
`vgpu.rs`. Sub-modules can then be named `vgpu/foo.rs`, `vgpu/bar.rs`,
and it will work just fine. Actually I think that's the preferred way of
organizing modules in R4L.

Generally speaking, let's keep mechanical changes, refactorings,
plumbing and only then new features each as separate patches. Not only
does this make it easier to review, it also will give you a better
perspective of your own code and make possible optimizations/reorderings
visible that are not obvious is everything is clumped together.