Re: [PATCH 05/13] gpu: nova-core: gsp: keep FMC boot params DMA region alive during error

["Eliot Courtney" <ecourtney@nvidia.com>]

On Wed Jun 17, 2026 at 10:52 PM JST, Gary Guo wrote:
> On Wed Jun 17, 2026 at 6:27 AM BST, Eliot Courtney wrote:
>> On Tue Jun 16, 2026 at 2:23 AM JST, Gary Guo wrote:
>>> On Mon Jun 15, 2026 at 3:40 PM BST, Eliot Courtney wrote:
>>>> Currently, if, for example `boot_fmc` fails, `FmcBootArgs` will be
>>>> dropped before the boot unload guard. But until everything is unloaded,
>>>> GSP may access this memory, so make sure it doesn't get deallocated.
>>>
>>> Hmm, this looks very weirld. `boot_fmc` only needs `&args` but it actually need
>>> it for much longer?
>>>
>>> This is hinting to me that the signature is wrong of the `boot_fmc` function is
>>> wrong..
>>>
>>> What is the exact lifetime requirement for GSP?
>>
>> Once `wait_for_gsp_lockdown_release` returns, it no longer needs the
>> allocation. In the case that we get an error in this function, GSP may
>> be (asychronously to the CPU) accessing the DMA memory we gave it. So
>> FmcBootArgs should stay alive until FspUnloadBundle finishes (GSP is
>> reset) if there is an error, or, until `wait_for_gsp_lockdown_release`
>> returns successfully.
>>
>> So for `boot_fmc` to cover the actual lifetime it would need to be
>> responsible for waiting until GSP is reset, which it doesn't feel like
>> it should be responsible for (even as some unload bundle that it
>> returns).
>
> I suppose logically the GSP does need to take ownership of the full `Coherent`
> until unload if this errors?

Yerp, although it would feel noisy to me to have GSP optionally hold this
value (if HAL requires it, if we had an error specifically during this
FSP window of time).