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

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

On Wed Jun 17, 2026 at 5:07 PM JST, Zhi Wang wrote:
> On Tue, 16 Jun 2026 23:20:41 +0900
> "Alexandre Courbot" <acourbot@nvidia.com> wrote:
>
>> On Thu Jun 4, 2026 at 8:43 PM JST, Zhi Wang wrote:
>
> snip
>
>> 
>> `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,
>>         }
>>     }
>> 
>
> Make sense. Let me try. 

Actually, please check my later reply to this patch [1]. We should be
able to completely get rid of this if we move the `Fsp` into `Gpu` as
described in [2].

[1] https://lore.kernel.org/all/DJAZT6ZNLZYZ.OJE0UIR4OOBQ@nvidia.com/
[2] https://lore.kernel.org/all/DJAZRULU1QHZ.2NSTR1ZPOQUSN@nvidia.com/

>
>> > +    ) -> Result<Self> {
>
> snip
>
>> > diff --git a/drivers/gpu/nova-core/gsp/fw.rs
>> > b/drivers/gpu/nova-core/gsp/fw.rs index 14424a2c2d83..2f3cbc5d5114
>> > 100644 --- a/drivers/gpu/nova-core/gsp/fw.rs
>> > +++ b/drivers/gpu/nova-core/gsp/fw.rs
>> > @@ -101,6 +101,18 @@ pub(in crate::gsp) fn
>> > advance_cpu_write_ptr(qs: &Coherent<GspMem>, count: u32) {
>> > pub(crate) const GSP_MSG_QUEUE_ELEMENT_SIZE_MAX: usize =
>> > num::u32_as_usize(bindings::GSP_MSG_QUEUE_ELEMENT_SIZE_MAX); 
>> > +const GSP_FW_HEAP_SIZE_VGPU_1VM: u64 = 174 * u64::SZ_1M;
>> > +const GSP_FW_HEAP_SIZE_VGPU_DEFAULT: u64 = 581 * u64::SZ_1M;
>> > +const GSP_FW_HEAP_SIZE_VGPU_48VMS: u64 = 1370 * u64::SZ_1M;  
>> 
>> Do we have a source of truth for these values? I can see definitions
>> for `GSP_FW_HEAP_SIZE_VGPU_DEFAULT` and `GSP_FW_HEAP_SIZE_VGPU_48VMS`
>> in OpenRM (meaning we could generate bindings for them), but cannot
>> find a reference for `GSP_FW_HEAP_SIZE_VGPU_1VM`...
>
> I see. Let me remove this one and we can add this when OpenRM has it.

I am fine with keeping it if it is useful, but would like to know how
its value was inferred. :)

And also, how stable these values are, since they will need to remain
stable across firmware releases. If they turn out to be
firmware-dependent, maybe we can turn them into TLV properties of the
firmware.