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

["Alexandre Courbot" <acourbot@nvidia.com>]

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.