Re: [PATCH v8 00/13] gpu: nova-core: add Turing support

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

On Sat Jan 24, 2026 at 3:36 AM JST, Gary Guo wrote:
> On Thu Jan 22, 2026 at 10:28 PM GMT, Timur Tabi wrote:
>> Note: This patchset requires "[PATCH v3 2/7] rust: io: always inline
>> functions using build_assert with arguments" in order to compile
>> with CLIPPY.
>>
>> This patch set adds basic support for pre-booting GSP-RM
>> on Turing.
>>
>> There is also partial support for GA100, but it's currently not
>> fully implemented.  GA100 is considered experimental in Nouveau,
>> and so it hasn't been tested with NovaCore either.
>>
>> The latest linux-firmware.git is required because it contains the
>> Generic Bootloader image that has not yet been propogated to
>> distros.
>>
>> Summary of changes:
>>
>> 1. Introduce non-secure IMEM support.  For GA102 and later, only secure IMEM
>> is used.
>> 2. Because of non-secure IMEM, Turing booter firmware images need some of
>> the headers parsed differently for stuff like the load target address.
>> 3. Add support the tu10x firmware signature section in the ELF image.
>> 4. Add several new registers used only on Turing.
>> 5. Some functions that were considered generic Falcon operations are
>> actually different on Turing vs GA102+, so they are moved to the HAL.
>> 6. The FRTS FWSEC firmware in VBIOS uses a different version of the
>> descriptor header.
>> 7. On Turing/GA100 LIBOS args struct needs to have its 'size' field
>> aligned to 4KB.  So pad the struct to make it 4K.
>> 8. Turing Falcons do not support DMA, so PIO is used to copy images
>> into IMEM/DMEM.
>> 9. Load the Generic Bootloader from disk and use it to boot FWSEC on
>> Turing and GA100.
>>
>> Changes from v7:
>> 1. Fix unused warnings in some commits that introduce an identifier
>> but don't actually use it until a later commit.
>> 2. Split out the Generic Bootloader code from the PIO code into a
>> separate patch.
>> 3. Removed accidentally included vbios.rs.orig
>
> I've checked the Rust language aspect of the series and on the internal API
> design and it looks good. I haven't checked that the actually hardware
> operations are functioning as intended, though.
>
> Danilo/Alex, feel free to convert this to an Reviewed-by or Acked-by, whichever
> you see fit.

Gratefully adding your Reviewed-by! :) Thanks for the review.