Re: [PATCH] gpu: nova-core: reserve a larger GSP WPR2 heap when vGPU is enabled

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

On Tue Jun 16, 2026 at 11:20 PM JST, Alexandre Courbot wrote:
> On Thu Jun 4, 2026 at 8:43 PM JST, Zhi Wang wrote:
>> GSP-RM allocates independent RM sub-heaps for each VF partition inside
>> the WPR2 region. The default baremetal heap sizing is far too small for
>> vGPU instance, causing GSP-RM to hit out-of-memory failures during VF
>> initialization.
>>
>> The host driver must reserve the correct heap size before GSP boots,
>> because the WPR2 region is locked down by the hardware after boot and
>> cannot be resized at runtime. The firmware determines the per-VF carve
>> from the gspFwHeapVfPartitionCount field in the WPR2 metadata header.
>>
>> Select a pre-calibrated static heap size based on total_vfs (174 MB for
>> 1 VM, 581 MB for 2-32 VFs, 1370 MB for 48 VFs) and set
>> vf_partition_count accordingly. Extend FbLayout::new() and
>> GspBootContext to propagate total_vfs through the boot path.
>>
>> Signed-off-by: Zhi Wang <zhiw@nvidia.com>
>> ---
>>  drivers/gpu/nova-core/fb.rs       | 17 +++++++++++++----
>>  drivers/gpu/nova-core/gsp.rs      |  2 +-
>>  drivers/gpu/nova-core/gsp/boot.rs | 14 +++++++++++---
>>  drivers/gpu/nova-core/gsp/fw.rs   | 12 ++++++++++++
>>  4 files changed, 37 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/nova-core/fb.rs b/drivers/gpu/nova-core/fb.rs
>> index 725e428154cf..fb4e6aa9fda4 100644
>> --- a/drivers/gpu/nova-core/fb.rs
>> +++ b/drivers/gpu/nova-core/fb.rs
>> @@ -171,7 +171,13 @@ pub(crate) struct FbLayout {
>>  
>>  impl FbLayout {
>>      /// Computes the FB layout for `chipset` required to run the `gsp_fw` GSP firmware.
>> -    pub(crate) fn new(chipset: Chipset, bar: Bar0<'_>, gsp_fw: &GspFirmware) -> Result<Self> {
>> +    pub(crate) fn new(
>> +        chipset: Chipset,
>> +        bar: Bar0<'_>,
>> +        gsp_fw: &GspFirmware,
>> +        vgpu_requested: bool,
>> +        total_vfs: u16,
>
> `total_vfs` is only meaningful if `vgpu_requested` is true. So these two
> parameters would be better modeled using an `Option`, or maybe even
> better a dedicated parameter type for vGPU settings? Something like
> (please pick a better name if any):
>
>     enum VgpuRequest {
>         Disabled,
>         Requested {
>             total_vfs: u16,
>         }
>     }

If we can implement my suggestion of moving `Fsp` into `Gpu` of patch
7, then this can take a `&VgpuManager` and not require any new type to
express the vGPU state.