Re: [PATCH v11 07/20] gpu: nova-core: mm: Add TLB flush support

[Joel Fernandes]

On 4/16/2026 6:53 PM, Danilo Krummrich wrote:
> On Fri Apr 17, 2026 at 12:18 AM CEST, Joel Fernandes wrote:
>> On 4/16/2026 5:45 PM, Danilo Krummrich wrote:
>>> Why do we need the try_access() dance in the first place? I assume this ends up
>>> being called from the BarAccess destructor?
>>
>> BarAccess is different. The try_access() calls here are in tlb.rs and
>> pramin.rs for Bar0.
> 
> Yes, and we shouldn't need them in the first place; we should have a
> &Device<Bound> in all call paths this is called from.
> 
>>> If so, I think this is solvable. Gary and me are currently working on
>>> higher-ranked types and a chained Devres type.
>>
>> Hmm, the issue here is we cannot hold revocable guard while sleeping, but
>> we have read the bar as a condition in the body of the poll.
> 
> No, you should just require a &Device<Bound>; or maybe we can utilize the
> mentioned higher-ranked types and DevresChain once we have it. But in any case
> you shouldn't need try_access() here.
> 
>>> With that, such use-cases should be cleanly solvable without the need for
>>> try_access().
>>>
>>> Besides that, I can't find where BarAccess is ever constructed.
>>
>> BarUser::map() constructs it.
> 
> I'm well aware, but absolutely nothing calls BarUser::map(). :)
> 
>>> It already has a lifetime 'a for &'a Bar1, so I don't see why you can't do the
>>> same for Bar0.>
>>> But again, I don't see this being constructed and I'm not sure the whole
>>> construct works in the first place.
>>
>> BarAccess uses &'a Bar1 because it's a short-lived scoped object. In long
>> lived objects I am trying to avoid this.
> 
> Don't get me wrong, if a lifetime is sufficient -- that's great! But I'm
> suspicious whether it actually is, since BarAccess is never actually constructed
> and hence I can't see how it would be used.

Doing some more research, the BAR1 read is required for vGPU bootload,
which happens from Driver initialization. The BarAccess (which I should
probably rename to `BarUserAccess`) is created, accessed and destroyed
before probe ends. So it appears for the moment (and for other scarcity
related points made above), I think keep Bar1 as a lifetime makes sense.

For the TLB and mm objects, I was trying to avoid using lifetimes. But as
you sort of indicated, Device<Bound> and hence Bar1 should outlive the MM
objects, so that sounds like the right approach. I will plan to have that
for v12.