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

[Joel Fernandes <joelagnelf@nvidia.com>]

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.

Actually, it is constructed in the self-test. Maybe you missed the
self-test patch?

    #[cfg(CONFIG_NOVA_MM_SELFTESTS)]
    fn run_mm_selftests(self: Pin<&mut Self>, pdev:
&pci::Device<device::Bound>) -> Result {
        // PRAMIN aperture self-tests.
        crate::mm::pramin::run_self_test(pdev.as_ref(), self.mm.pramin())?;

        // BAR1 self-tests.
        let bar1 = Arc::pin_init(pdev.iomap_region(1, c"nova-core/bar1"),
GFP_KERNEL)?;
        let bar1_access = bar1.access(pdev.as_ref())?;

        crate::mm::bar_user::run_self_test(
            pdev.as_ref(),
            &self.mm,
            bar1_access,
            self.gsp_static_info.bar1_pde_base,
            self.spec.chipset,
        )?;

        Ok(())
    }

However, you do raise a good point -- may we cannot assume that BAR1
reference is short lived. One thing though is typically BAR1 size is
limited, so we should not allow anyone to use it for long-lived usecases to
prevent filling up the small BAR1 aperture into VRAM.

The user of the bar1 code is vGPU at the moment, I am sure in the future we
will have other uses of the CPU directly accessing VRAM. Zhi, can you share
any thoughts here? Is BAR1 for vGPU expected to be held long-lived?

I agree with your points about Device<Bound> and I will explore that as well.