Re: [PATCH] gpu: nova-core: make pramin/buddy optional

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

On Fri Oct 30, 2026 at 12:51 PM JST, Alexandre Courbot wrote:
[...]
>> @@ -85,28 +85,28 @@ impl<'gpu> GpuMm<'gpu> {
>>      pub(crate) fn new(
>>          bar: Bar0<'gpu>,
>>          chipset: Chipset,
>> -        buddy_params: GpuBuddyParams,
>> -        total_fb_end: VramAddress,
>> +        buddy_params: Option<GpuBuddyParams>,
>> +        total_fb_end: Option<VramAddress>,
>
> This is related to the comment made by Sashiko, but in which cases are
> we expecting `total_fb_end` to be `None` here? Is this the same set of
> systems for which `buddy_params` will be `None`? If so both arguments
> should be merged into a new type to remove the ability to represent
> invalid state where one is `Some` and the other is `None`.

Agree with this here - these both rely on vram existing so nice to group
them.


[...]
>>      ) -> Result {
>>          {
>> -            let pramin = mm.pramin_mut();
>> +            let pramin = mm.pramin_mut()?;
>>  
>>              // Drain prepared PT pages, install all pending PDEs.
>>              let mut cursor = pt_pages.cursor_front_mut();
>> @@ -255,7 +255,7 @@ pub(super) fn invalidate_ptes(
>>          let invalid_pte = M::Pte::invalid();
>>  
>>          {
>> -            let pramin = mm.pramin_mut();
>> +            let pramin = mm.pramin_mut()?;
>
> I'll let Eliot comment on this in more depth as I am not very familiar
> with this module, but I'd like to avoid these runtime checks if
> possible. On systems without a framebuffer, we should not even be able
> to call these methods, so I'd like to enforce it at that level.
>
> Ideally, we would consolidate all the state requiring a framebuffer into
> a new type (i.e. my first comment, but pushed further), and put it
> behind a single `Option` that solely tells us whether the system has a
> framebuffer or not. Then methods requiring a framebuffer can be passed a
> reference to that type and work without runtime checking its presence.

I think that we can't just put both pramin and buddy/etc into a single
struct for vram-less systems. For example, for vGPU guest, pramin isn't
available (but we still have physical vram to allocate). We have some
matrix more like:

VRAM: exists(need physical alloc)/doesn't exist(use sysmem)
Pramin: exists(bootstrapping ptes)/exists(not using it)/doesn't exist
CPU->VRAM access: pramin/bar1+bar2/coherent link/no vram

So these things kinda end up having to be handled separately, afaict. We
will still have to manipulate GPU page tables even on systems that have
no vram/framebuffer.

The current method of always using pramin to write page tables needs to
be reworked and abstracted (I'm looking into it), since pramin may not
be available, and the method to write the page tables could be one of a
few things (pramin, bar2, sysmem, copy engine).

Given that this needs to be reworked regardless (e.g. map.rs should not
be using pramin directly) I think this is a reasonable short term
workaround tbh.