Re: [PATCH v2] gpu: nova-core: fix stack overflow in GSP memory allocation

[Gary Guo <gary@garyguo.net>]

On 2026-02-14 00:09, Danilo Krummrich wrote:
> On Sat Feb 14, 2026 at 12:50 AM CET, gary wrote:
>> If you prefer, I can send out a version with just improved projections 
>> without
>> all the generic I/O improvement stuff.
> 
> Yes, that would be great. Otherwise, we can also use as_slice_mut() to 
> avoid
> having to touch field_write() directly, but I much prefer the former.
> 
> In any case, I'd like to keep the PteArray type. It can at least 
> provide a
> function to calculate the value from the DMA address for a given index.
> 
> (Would be nice if we'd have something like a dma::Projection<T> type, 
> such that we
> could have PteArray::init(self: dma::Projection<Self>).)

I think once I/O projection work is done, this would just be

impl PteArray {
     fn init<Base>(self: io::View<'_, Base, Self>>, dma: DmaAddress)
}

and the generic I/O projection is used inside.

Best,
Gary

> 
>> I've already suggested that in
>> https://rust-for-linux.zulipchat.com/#narrow/channel/509436-Nova/topic/.60Cmdq.3A.3Anew.60.20uses.20excessive.20stack.20size/near/570456463.
>> The issue is that however the PTE array needs the actual DMA address 
>> to
>> initialize, which Alex and I feel that we shouldn't provide to the 
>> initializer
>> when `dma::CoherentAllocation` is not yet constructed.
> 
> Ah, indeed -- that sucks.
> 
> And yes, it would be super pointless to give out the actual DMA address 
> in the
> initializer, as it would defeat its whole purpose. :)