This series adds support for nova-core memory management, including VRAM
allocation, PRAMIN, VMM, page table walking, and BAR 1 read/writes.
These are critical for channel management, vGPU, and all memory
management uses.

These patches depend on the following preparatory patches:
https://lore.kernel.org/all/20260218205507.689429-1-joelagnelf@nvidia.com/T/#t

All patches (including the preparatory patches from the other series) can
be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git (branch nova/mm or tag: nova-mm-v7-20260218)

Earlier series of these patches:
https://lore.kernel.org/linux-fbdev/DG0MRL6T7ACW.25G3GLJMP7PN1@kernel.org/T/#t
https://lore.kernel.org/linux-fbdev/20260210233204.790524-1-joelagnelf@nvidia.com/

Joel Fernandes (23):
  nova-core: mm: Add support to use PRAMIN windows to write to VRAM
  docs: gpu: nova-core: Document the PRAMIN aperture mechanism
  nova-core: Add BAR1 aperture type and size constant
  nova-core: gsp: Add BAR1 PDE base accessors
  nova-core: mm: Add common memory management types
  nova-core: mm: Add common types for all page table formats
  nova-core: mm: Add MMU v2 page table types
  nova-core: mm: Add MMU v3 page table types
  nova-core: mm: Add unified page table entry wrapper enums
  nova-core: mm: Add TLB flush support
  nova-core: mm: Add GpuMm centralized memory manager
  nova-core: mm: Add page table walker for MMU v2/v3
  nova-core: mm: Add Virtual Memory Manager
  nova-core: mm: Add virtual address range tracking to VMM
  nova-core: mm: Add multi-page mapping API to VMM
  nova-core: mm: Add BAR1 user interface
  nova-core: gsp: Return GspStaticInfo and FbLayout from boot()
  nova-core: mm: Add BAR1 memory management self-tests
  nova-core: mm: Add PRAMIN aperture self-tests
  nova-core: gsp: Extract usable FB region from GSP
  nova-core: fb: Add usable_vram field to FbLayout
  nova-core: mm: Use usable VRAM region for buddy allocator
  nova-core: mm: Add BarUser to struct Gpu and create at boot

 Documentation/gpu/nova/core/pramin.rst     | 125 ++++++
 Documentation/gpu/nova/index.rst           |   1 +
 drivers/gpu/nova-core/Kconfig              |  10 +
 drivers/gpu/nova-core/driver.rs            |   9 +-
 drivers/gpu/nova-core/fb.rs                |  23 +-
 drivers/gpu/nova-core/gpu.rs               | 135 +++++-
 drivers/gpu/nova-core/gsp/boot.rs          |  22 +-
 drivers/gpu/nova-core/gsp/commands.rs      |  18 +-
 drivers/gpu/nova-core/gsp/fw/commands.rs   |  38 ++
 drivers/gpu/nova-core/mm/bar_user.rs       | 318 ++++++++++++++
 drivers/gpu/nova-core/mm/mod.rs            | 241 +++++++++++
 drivers/gpu/nova-core/mm/pagetable/mod.rs  | 479 +++++++++++++++++++++
 drivers/gpu/nova-core/mm/pagetable/ver2.rs | 199 +++++++++
 drivers/gpu/nova-core/mm/pagetable/ver3.rs | 302 +++++++++++++
 drivers/gpu/nova-core/mm/pagetable/walk.rs | 213 +++++++++
 drivers/gpu/nova-core/mm/pramin.rs         | 454 +++++++++++++++++++
 drivers/gpu/nova-core/mm/tlb.rs            |  92 ++++
 drivers/gpu/nova-core/mm/vmm.rs            | 473 ++++++++++++++++++++
 drivers/gpu/nova-core/nova_core.rs         |   1 +
 drivers/gpu/nova-core/regs.rs              |  38 ++
 20 files changed, 3182 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/gpu/nova/core/pramin.rst
 create mode 100644 drivers/gpu/nova-core/mm/bar_user.rs
 create mode 100644 drivers/gpu/nova-core/mm/mod.rs
 create mode 100644 drivers/gpu/nova-core/mm/pagetable/mod.rs
 create mode 100644 drivers/gpu/nova-core/mm/pagetable/ver2.rs
 create mode 100644 drivers/gpu/nova-core/mm/pagetable/ver3.rs
 create mode 100644 drivers/gpu/nova-core/mm/pagetable/walk.rs
 create mode 100644 drivers/gpu/nova-core/mm/pramin.rs
 create mode 100644 drivers/gpu/nova-core/mm/tlb.rs
 create mode 100644 drivers/gpu/nova-core/mm/vmm.rs

-- 
2.34.1

Hi Joel,

On Thu Feb 19, 2026 at 6:19 AM JST, Joel Fernandes wrote:
> This series adds support for nova-core memory management, including VRAM
> allocation, PRAMIN, VMM, page table walking, and BAR 1 read/writes.
> These are critical for channel management, vGPU, and all memory
> management uses.
>
> These patches depend on the following preparatory patches:
> https://lore.kernel.org/all/20260218205507.689429-1-joelagnelf@nvidia.com/T/#t
>
> All patches (including the preparatory patches from the other series) can
> be found at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git (branch nova/mm or tag: nova-mm-v7-20260218)
>
> Earlier series of these patches:
> https://lore.kernel.org/linux-fbdev/DG0MRL6T7ACW.25G3GLJMP7PN1@kernel.org/T/#t
> https://lore.kernel.org/linux-fbdev/20260210233204.790524-1-joelagnelf@nvidia.com/
>
> Joel Fernandes (23):
>   nova-core: mm: Add support to use PRAMIN windows to write to VRAM
>   docs: gpu: nova-core: Document the PRAMIN aperture mechanism
>   nova-core: Add BAR1 aperture type and size constant
>   nova-core: gsp: Add BAR1 PDE base accessors
>   nova-core: mm: Add common memory management types
>   nova-core: mm: Add common types for all page table formats
>   nova-core: mm: Add MMU v2 page table types
>   nova-core: mm: Add MMU v3 page table types
>   nova-core: mm: Add unified page table entry wrapper enums
>   nova-core: mm: Add TLB flush support
>   nova-core: mm: Add GpuMm centralized memory manager
>   nova-core: mm: Add page table walker for MMU v2/v3
>   nova-core: mm: Add Virtual Memory Manager
>   nova-core: mm: Add virtual address range tracking to VMM
>   nova-core: mm: Add multi-page mapping API to VMM
>   nova-core: mm: Add BAR1 user interface
>   nova-core: gsp: Return GspStaticInfo and FbLayout from boot()
>   nova-core: mm: Add BAR1 memory management self-tests
>   nova-core: mm: Add PRAMIN aperture self-tests
>   nova-core: gsp: Extract usable FB region from GSP
>   nova-core: fb: Add usable_vram field to FbLayout
>   nova-core: mm: Use usable VRAM region for buddy allocator
>   nova-core: mm: Add BarUser to struct Gpu and create at boot

Nice series, a few overall remarks before I dive deeper into each patch:

- Use `gpu: nova-core:` (not just `nova-core:`) as the patch prefix.
- There were a few clippy warnings/rustfmt diffs when I built it.
- There are build failures introduced in patches 11 and 18 - basically
  the series doesn't build from 11 until the last patch.
- This patchset is using the `module/mod.rs` pattern instead of
  `module.rs` for new modules. The latter is the preferred norm IIUC.

The end result of the series looks coherent, but the ordering of patches
makes it more tedious to review than it needs to be. We start with
PRAMIN, then add some BAR1 types that are not used until 10+ patches
later, switch to getting the framebuffer size from the GSP, add tests,
go back to GSP, etc. It is difficult to follow all these intertwined
topics (even though they eventually converge) and to know which of the
previous patches are relevant to the current one.

But there is a clear path, and after moving patches around (with only
very trivial conflicts) I got the following ordering which is more
logical IMHO:

Phase 1: GSP plumbing
- nova-core: gsp: Return GspStaticInfo and FbLayout from boot()
- nova-core: gsp: Extract usable FB region from GSP
- nova-core: fb: Add usable_vram field to FbLayout

These constitute a logical change by themselves, by getting more
information from the GSP to know how much VRAM we have. You could even
display the result as a dev_info of dev_dbg to remove the only remaining
`dead_code`.

Phase 2: PRAMIN support
- nova-core: mm: Add support to use PRAMIN windows to write to VRAM
- docs: gpu: nova-core: Document the PRAMIN aperture mechanism

PRAMIN is needed by everything that follows.

Phase 3: GpuMm
- nova-core: mm: Add common memory management types
- nova-core: mm: Add TLB flush support
- nova-core: mm: Add GpuMm centralized memory manager
- nova-core: mm: Use usable VRAM region for buddy allocator

The common memory management types patch and TLB give us all we need to
introduce GpuMm, which makes it more accessible that after going through
all the page table types which it doesn't depend on. This culminates
with using the result of phase 1, which also allows you to get rid of
the temporary 1MB window hack if you rearrange the code a bit.

Phase 4: page tables / VMM
- nova-core: mm: Add common types for all page table formats
- nova-core: mm: Add MMU v2 page table types
- nova-core: mm: Add MMU v3 page table types
- nova-core: mm: Add unified page table entry wrapper enums
- nova-core: mm: Add page table walker for MMU v2/v3
- nova-core: mm: Add Virtual Memory Manager
- nova-core: mm: Add virtual address range tracking to VMM
- nova-core: mm: Add multi-page mapping API to VMM

The main course, required for BAR1 - these follow the original order.

Phase 5: BAR1
- nova-core: Add BAR1 aperture type and size constant
- nova-core: gsp: Add BAR1 PDE base accessors
- nova-core: mm: Add BAR1 user interface
- nova-core: mm: Add BarUser to struct Gpu and create at boot

All the BAR1 stuff now happens in one place. There is certainly room for
merging a few patches to avoid introducing dead code and eliminating
just after.

Phase 6: tests
- nova-core: mm: Add PRAMIN aperture self-tests
- nova-core: mm: Add BAR1 memory management self-tests

I have done this reordering locally and it seems to build fine.

I'll do a patch-by-patch review following this order, but I wanted to
share it first for other reviewers of this revision as it makes the
series more accessible IMHO.

Hi Alex,

Thanks for taking the time to go through the series and for the effort
of doing the reordering. Just to clarify, do you mean I should be
sending each of the phases separately for review instead of in one
series?

By any chance, do you have the tree after doing the rearrangement that I
could take a look at? That would be very helpful so I don't repeat your
rearrangement effort.

Some comments below:

> Nice series, a few overall remarks before I dive deeper into each patch:
>
> - Use `gpu: nova-core:` (not just `nova-core:`) as the patch prefix.

Done.

> - There were a few clippy warnings/rustfmt diffs when I built it.
> - There are build failures introduced in patches 11 and 18 - basically
>   the series doesn't build from 11 until the last patch.
> - This patchset is using the `module/mod.rs` pattern instead of
>   `module.rs` for new modules. The latter is the preferred norm IIUC.

I will work on fixing these based on the reordered patches for the next
spin.

> Phase 1: GSP plumbing
> - nova-core: gsp: Return GspStaticInfo and FbLayout from boot()
> - nova-core: gsp: Extract usable FB region from GSP
> - nova-core: fb: Add usable_vram field to FbLayout
>
> These constitute a logical change by themselves, by getting more
> information from the GSP to know how much VRAM we have. You could even
> display the result as a dev_info of dev_dbg to remove the only remaining
> `dead_code`.

This looks good to me.

> Phase 2: PRAMIN support
> - nova-core: mm: Add support to use PRAMIN windows to write to VRAM
> - docs: gpu: nova-core: Document the PRAMIN aperture mechanism
>
> PRAMIN is needed by everything that follows.

This looks good to me.

> Phase 3: GpuMm
> - nova-core: mm: Add common memory management types
> - nova-core: mm: Add TLB flush support
> - nova-core: mm: Add GpuMm centralized memory manager
> - nova-core: mm: Use usable VRAM region for buddy allocator
>
> The common memory management types patch and TLB give us all we need to
> introduce GpuMm, which makes it more accessible that after going through
> all the page table types which it doesn't depend on. This culminates
> with using the result of phase 1, which also allows you to get rid of
> the temporary 1MB window hack if you rearrange the code a bit.

Yeah, that is a nice advantage!

> Phase 4: page tables / VMM
> - nova-core: mm: Add common types for all page table formats
> - nova-core: mm: Add MMU v2 page table types
> - nova-core: mm: Add MMU v3 page table types
> - nova-core: mm: Add unified page table entry wrapper enums
> - nova-core: mm: Add page table walker for MMU v2/v3
> - nova-core: mm: Add Virtual Memory Manager
> - nova-core: mm: Add virtual address range tracking to VMM
> - nova-core: mm: Add multi-page mapping API to VMM
>
> The main course, required for BAR1 - these follow the original order.

Sounds good.

> Phase 5: BAR1
> - nova-core: Add BAR1 aperture type and size constant
> - nova-core: gsp: Add BAR1 PDE base accessors
> - nova-core: mm: Add BAR1 user interface
> - nova-core: mm: Add BarUser to struct Gpu and create at boot

These sound good to me.

> All the BAR1 stuff now happens in one place. There is certainly room for
> merging a few patches to avoid introducing dead code and eliminating
> just after.

Yeah, I tried to keep the commits at a reasonable size to make review
easier. I will look into merging a little more to see where it is possible.

> Phase 6: tests
> - nova-core: mm: Add PRAMIN aperture self-tests
> - nova-core: mm: Add BAR1 memory management self-tests

This sounds good to me.

> I have done this reordering locally and it seems to build fine.

Please share your reorder tree if you still have it. That would likely save
me a lot of effort. Thanks.

> I'll do a patch-by-patch review following this order, but I wanted to
> share it first for other reviewers of this revision as it makes the
> series more accessible IMHO.

Looking forward to it. Thanks!

--
Joel Fernandes

On Fri Feb 20, 2026 at 4:48 AM JST, Joel Fernandes wrote:
> Hi Alex,
>
> Thanks for taking the time to go through the series and for the effort
> of doing the reordering. Just to clarify, do you mean I should be
> sending each of the phases separately for review instead of in one
> series?

Sorry, forgot to reply to this. I think one series is fine now that
CList/buddy have been moved out, as it only spans one component
(nova-core) and forces us to keep the big picture in mind. The
reordering is just to enable a more granular review process and identify
the moving pieces more clearly.

On Fri Feb 20, 2026 at 4:48 AM JST, Joel Fernandes wrote:
> Hi Alex,
>
> Thanks for taking the time to go through the series and for the effort
> of doing the reordering. Just to clarify, do you mean I should be
> sending each of the phases separately for review instead of in one
> series?
>
> By any chance, do you have the tree after doing the rearrangement that I
> could take a look at? That would be very helpful so I don't repeat your
> rearrangement effort.

Sure: https://github.com/Gnurou/linux/tree/review/nova-mm-v10

I have rebased it on top of your `nova-mm-v7-20260218` tag, hopefully
that makes it easier to pick.

The top-of-trees of both my branch and your tag are identical, and I've
tried to limit the changes in each patch, but you will want to quickly
check them. I have fixed the transient build errors, but not the
formatting or clippy warnings to make sure my top-of-tree stayed
identical to yours and I haven't introduced any regression.