Re: [PATCH v5 6/6] gpu: nova-core: reserve vGPU WPR2 heap

[email protected] Wed, 22 Jul 2026 07:52:34 +0000
Newsgroups dev.linux.lists.nova-gpu,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unchecked subtractions during framebuffer layout calculation can underflow if the device's video memory size is unexpectedly small.
--

--- Patch [6]: [PATCH v5 6/6] gpu: nova-core: reserve vGPU WPR2 heap ---
commit f23fa75b7168b0143fdda0d52c83938a849ca02d
Author: Zhi Wang <[email protected]>

gpu: nova-core: reserve vGPU WPR2 heap

This commit updates the framebuffer layout calculation to pass the detected
vGPU state. It keeps baremetal boots on the existing heap sizing path and
uses a firmware-dependent 570.144 vGPU default heap binding when vGPU is
enabled.

> diff --git a/drivers/gpu/nova-core/fb.rs b/drivers/gpu/nova-core/fb.rs
> --- a/drivers/gpu/nova-core/fb.rs
> +++ b/drivers/gpu/nova-core/fb.rs
[ ... ]
> @@ -234,10 +240,19 @@ pub(crate) fn new(chipset: Chipset, bar: Bar0<'_>, gsp_fw: &GspFirmware) -> Resu
>              FbRange(elf_addr..elf_addr + elf_size)
>          };
>  
> +        let (vf_partition_count, wpr2_heap_size) = match vgpu_state {
> +            VgpuState::Disabled => (
> +                0,
> +                gsp::LibosParams::from_chipset(chipset).wpr_heap_size(chipset, fb.end)?,
> +            ),
> +            VgpuState::Enabled { total_vfs } => (
> +                u8::try_from(total_vfs.get()).map_err(|_| EINVAL)?,
> +                gsp::LibosParams::vgpu_wpr_heap_size(),
> +            ),
> +        };
> +
>          let wpr2_heap = {
>              const WPR2_HEAP_DOWN_ALIGN: Alignment = Alignment::new::<SZ_1M>();
> -            let wpr2_heap_size =
> -                gsp::LibosParams::from_chipset(chipset).wpr_heap_size(chipset, fb.end)?;
>              let wpr2_heap_addr = (elf.start - wpr2_heap_size).align_down(WPR2_HEAP_DOWN_ALIGN);

[Severity: High]
This is a pre-existing issue, but could this subtraction underflow if the
hardware or a hypervisor reports a malformed, undersized framebuffer?

Since this patch introduces a hardcoded ~581MB requirement for
wpr2_heap_size in vGPU mode, the risk seems significantly amplified. If the
hardware-reported video memory size isn't large enough to contain the
bootloader, elf, and this new large heap, elf.start - wpr2_heap_size will
either panic or wrap around to a massive out-of-bounds address.

Should there be a validation check against the total fb_size before
allocating these ranges backwards from the end of the framebuffer?

-- 
Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=6