These patches have some prerequistes needed for nova-core as support is added
for memory management and interrupt handling. I rebased them on drm-rust-next
and would like them to be considered for the next merge window. I also included
a simple rust documentation patch fixing some issues I noticed while reading it :).

The series adds support for the PRAMIN aperture mechanism, which is a
prerequisite for virtual memory as it is required to boot strap virtual memory
(we cannot write to VRAM using virtual memory because we need to write page
tables to VRAM in the first place).

I also add page table related structures (mm/types.rs) using the bitfield
macro, which will be used for page table walking, memory mapping, etc. This is
currently unused code, because without physical memory allocation (using the
buddy allocator), we cannot use this code as page table pages need to be
allocated in the first place. However, I have included several examples in the
file about how these structures will be used. I have also simplified the code
keeping future additions to it for later.

For interrupts, I only have added additional support for GSP's message queue
interrupt. I am working on adding support to the interrupt controller module
(VFN) which is the next thing for me to post after this series. I have it
prototyped and working, however I am currently making several changes to it
related to virtual functions. For now in this series, I just want to get the
GSP-specific patch out of the way, hence I am including it here.

I also have added a patch for bitfield macro which constructs a bitfield struct
given its storage type. This is used in a later GSP interrupt patch in the
series to read from one register and write to another.

Joel Fernandes (7):
  docs: rust: Fix a few grammatical errors
  gpu: nova-core: Add support to convert bitfield to underlying type
  docs: gpu: nova-core: Document GSP RPC message queue architecture
  docs: gpu: nova-core: Document the PRAMIN aperture mechanism
  gpu: nova-core: Add support for managing GSP falcon interrupts
  nova-core: mm: Add support to use PRAMIN windows to write to VRAM
  nova-core: mm: Add data structures for page table management

 Documentation/gpu/nova/core/msgq.rst     | 159 +++++++++
 Documentation/gpu/nova/core/pramin.rst   | 113 +++++++
 Documentation/gpu/nova/index.rst         |   2 +
 Documentation/rust/coding-guidelines.rst |   4 +-
 drivers/gpu/nova-core/bitfield.rs        |   7 +
 drivers/gpu/nova-core/falcon/gsp.rs      |  26 +-
 drivers/gpu/nova-core/gpu.rs             |   2 +-
 drivers/gpu/nova-core/mm/mod.rs          |   4 +
 drivers/gpu/nova-core/mm/pramin.rs       | 241 ++++++++++++++
 drivers/gpu/nova-core/mm/types.rs        | 405 +++++++++++++++++++++++
 drivers/gpu/nova-core/nova_core.rs       |   1 +
 drivers/gpu/nova-core/regs.rs            |  39 ++-
 12 files changed, 996 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/gpu/nova/core/msgq.rst
 create mode 100644 Documentation/gpu/nova/core/pramin.rst
 create mode 100644 drivers/gpu/nova-core/mm/mod.rs
 create mode 100644 drivers/gpu/nova-core/mm/pramin.rs
 create mode 100644 drivers/gpu/nova-core/mm/types.rs

-- 
2.34.1

On 10/20/25 11:55 AM, Joel Fernandes wrote:
> These patches have some prerequistes needed for nova-core as support is added
> for memory management and interrupt handling. I rebased them on drm-rust-next
> and would like them to be considered for the next merge window. I also included
> a simple rust documentation patch fixing some issues I noticed while reading it :).

Just to be clear, it appears to me that one must first apply
"[PATCH v7 0/4] bitfield initial refactor within nova-core" [1],
in order to apply this series, yes?


[1] https://lore.kernel.org/20251016150204.1189641-1-joelagnelf@nvidia.com


thanks,
-- 
John Hubbard

> 
> The series adds support for the PRAMIN aperture mechanism, which is a
> prerequisite for virtual memory as it is required to boot strap virtual memory
> (we cannot write to VRAM using virtual memory because we need to write page
> tables to VRAM in the first place).
> 
> I also add page table related structures (mm/types.rs) using the bitfield
> macro, which will be used for page table walking, memory mapping, etc. This is
> currently unused code, because without physical memory allocation (using the
> buddy allocator), we cannot use this code as page table pages need to be
> allocated in the first place. However, I have included several examples in the
> file about how these structures will be used. I have also simplified the code
> keeping future additions to it for later.
> 
> For interrupts, I only have added additional support for GSP's message queue
> interrupt. I am working on adding support to the interrupt controller module
> (VFN) which is the next thing for me to post after this series. I have it
> prototyped and working, however I am currently making several changes to it
> related to virtual functions. For now in this series, I just want to get the
> GSP-specific patch out of the way, hence I am including it here.
> 
> I also have added a patch for bitfield macro which constructs a bitfield struct
> given its storage type. This is used in a later GSP interrupt patch in the
> series to read from one register and write to another.
> 
> Joel Fernandes (7):
>   docs: rust: Fix a few grammatical errors
>   gpu: nova-core: Add support to convert bitfield to underlying type
>   docs: gpu: nova-core: Document GSP RPC message queue architecture
>   docs: gpu: nova-core: Document the PRAMIN aperture mechanism
>   gpu: nova-core: Add support for managing GSP falcon interrupts
>   nova-core: mm: Add support to use PRAMIN windows to write to VRAM
>   nova-core: mm: Add data structures for page table management
> 
>  Documentation/gpu/nova/core/msgq.rst     | 159 +++++++++
>  Documentation/gpu/nova/core/pramin.rst   | 113 +++++++
>  Documentation/gpu/nova/index.rst         |   2 +
>  Documentation/rust/coding-guidelines.rst |   4 +-
>  drivers/gpu/nova-core/bitfield.rs        |   7 +
>  drivers/gpu/nova-core/falcon/gsp.rs      |  26 +-
>  drivers/gpu/nova-core/gpu.rs             |   2 +-
>  drivers/gpu/nova-core/mm/mod.rs          |   4 +
>  drivers/gpu/nova-core/mm/pramin.rs       | 241 ++++++++++++++
>  drivers/gpu/nova-core/mm/types.rs        | 405 +++++++++++++++++++++++
>  drivers/gpu/nova-core/nova_core.rs       |   1 +
>  drivers/gpu/nova-core/regs.rs            |  39 ++-
>  12 files changed, 996 insertions(+), 7 deletions(-)
>  create mode 100644 Documentation/gpu/nova/core/msgq.rst
>  create mode 100644 Documentation/gpu/nova/core/pramin.rst
>  create mode 100644 drivers/gpu/nova-core/mm/mod.rs
>  create mode 100644 drivers/gpu/nova-core/mm/pramin.rs
>  create mode 100644 drivers/gpu/nova-core/mm/types.rs
>

On 10/20/2025 5:20 PM, John Hubbard wrote:
> On 10/20/25 11:55 AM, Joel Fernandes wrote:
>> These patches have some prerequistes needed for nova-core as support is added
>> for memory management and interrupt handling. I rebased them on drm-rust-next
>> and would like them to be considered for the next merge window. I also included
>> a simple rust documentation patch fixing some issues I noticed while reading it :).
> 
> Just to be clear, it appears to me that one must first apply
> "[PATCH v7 0/4] bitfield initial refactor within nova-core" [1],
> in order to apply this series, yes?
> 
> 
> [1] https://lore.kernel.org/20251016150204.1189641-1-joelagnelf@nvidia.com
> 

Yes that is correct. These patches are now in drm-rust-next and I clarified this
yesterday with Alex as well. Sorry I should have mentioned it in the cover letter.

Thanks.

On Tue Oct 21, 2025 at 3:55 AM JST, Joel Fernandes wrote:
> These patches have some prerequistes needed for nova-core as support is added
> for memory management and interrupt handling. I rebased them on drm-rust-next
> and would like them to be considered for the next merge window. I also included
> a simple rust documentation patch fixing some issues I noticed while reading it :).
>
> The series adds support for the PRAMIN aperture mechanism, which is a
> prerequisite for virtual memory as it is required to boot strap virtual memory
> (we cannot write to VRAM using virtual memory because we need to write page
> tables to VRAM in the first place).
>
> I also add page table related structures (mm/types.rs) using the bitfield
> macro, which will be used for page table walking, memory mapping, etc. This is
> currently unused code, because without physical memory allocation (using the
> buddy allocator), we cannot use this code as page table pages need to be
> allocated in the first place. However, I have included several examples in the
> file about how these structures will be used. I have also simplified the code
> keeping future additions to it for later.
>
> For interrupts, I only have added additional support for GSP's message queue
> interrupt. I am working on adding support to the interrupt controller module
> (VFN) which is the next thing for me to post after this series. I have it
> prototyped and working, however I am currently making several changes to it
> related to virtual functions. For now in this series, I just want to get the
> GSP-specific patch out of the way, hence I am including it here.
>
> I also have added a patch for bitfield macro which constructs a bitfield struct
> given its storage type. This is used in a later GSP interrupt patch in the
> series to read from one register and write to another.

So IIUC, this series contains the following:

1. Add PRAMIN support,
2. Add Page mapping support, albeit this is unexercised until we have a
   user (e.g. buddy allocator),
3. Add Falcon interrupt support,
4. Add missing bitfield functionality, albeit not used yet,
5. Various documentation patches.

This is a bit confusing, as there is close to no logical relationship or
dependency between these patches. I see potential for several different
submissions here:

- The core documentation fix, as Miguel pointed out, since it should be
  merged into the rust tree and not nova-core.
- The bitfield patch is a useful addition and should be sent separately.
- PRAMIN/Page mapping should come with code that exercices them, so
  think they belong as the first patches of a series that ends with
  basic memory allocation capabilities. But feel free to send a RFC if
  you want early feedback.
- The falcon interrupts patch does not seem to be used by the last two
  patches? I guess it belongs to the series that will add support for
  the interrupt controller.
- Other documentation patches belong to the series that introduces the
  feature they document.

Hi Alex,

On 10/22/2025 2:57 AM, Alexandre Courbot wrote:
> On Tue Oct 21, 2025 at 3:55 AM JST, Joel Fernandes wrote:
>> These patches have some prerequistes needed for nova-core as support is added
>> for memory management and interrupt handling. I rebased them on drm-rust-next
>> and would like them to be considered for the next merge window. I also included
>> a simple rust documentation patch fixing some issues I noticed while reading it :).
>>
>> The series adds support for the PRAMIN aperture mechanism, which is a
>> prerequisite for virtual memory as it is required to boot strap virtual memory
>> (we cannot write to VRAM using virtual memory because we need to write page
>> tables to VRAM in the first place).
>>
>> I also add page table related structures (mm/types.rs) using the bitfield
>> macro, which will be used for page table walking, memory mapping, etc. This is
>> currently unused code, because without physical memory allocation (using the
>> buddy allocator), we cannot use this code as page table pages need to be
>> allocated in the first place. However, I have included several examples in the
>> file about how these structures will be used. I have also simplified the code
>> keeping future additions to it for later.
>>
>> For interrupts, I only have added additional support for GSP's message queue
>> interrupt. I am working on adding support to the interrupt controller module
>> (VFN) which is the next thing for me to post after this series. I have it
>> prototyped and working, however I am currently making several changes to it
>> related to virtual functions. For now in this series, I just want to get the
>> GSP-specific patch out of the way, hence I am including it here.
>>
>> I also have added a patch for bitfield macro which constructs a bitfield struct
>> given its storage type. This is used in a later GSP interrupt patch in the
>> series to read from one register and write to another.
> 
> So IIUC, this series contains the following:
> 
> 1. Add PRAMIN support,
> 2. Add Page mapping support, albeit this is unexercised until we have a
>    user (e.g. buddy allocator),
> 3. Add Falcon interrupt support,
> 4. Add missing bitfield functionality, albeit not used yet,
> 5. Various documentation patches.
> 
> This is a bit confusing, as there is close to no logical relationship or
> dependency between these patches. I see potential for several different
> submissions here:
> 
> - The core documentation fix, as Miguel pointed out, since it should be
>   merged into the rust tree and not nova-core.
> - The bitfield patch is a useful addition and should be sent separately.
> - PRAMIN/Page mapping should come with code that exercices them, so
>   think they belong as the first patches of a series that ends with
>   basic memory allocation capabilities. But feel free to send a RFC if
>   you want early feedback.

Ah, so if we go with that - the mm patches here (Pramin and page structures
types) will then have to wait till we have DRM buddy bindings or a DRM buddy
written in rust (the latter of which I already have). That would be unfortunate
because it will take more time up in the future to rebase. But RFC is a good
idea too for just getting an advance review. I think we need to carefully choose
RFC versus merging small (even if unused) patches (more below).

> - The falcon interrupts patch does not seem to be used by the last two
>   patches? I guess it belongs to the series that will add support for
>   the interrupt controller.
No, it is independent. Yes this leads up to the interrupt handing feature, but
just to emphasize a bit, the motivation was to "get small patches" in so that we
don't need to do obvious things later (example, the VFN interrupt module is much
more complex than this GSP patch yet both are needed for interrupt handling, so
the GSP patch is a good candidate IMO for upstreaming in the next merge window).
Having small patches merged reduces future burden on both reviewers and the
developers. This is also not something new, for instance we don't have any users
of the PCI MSI IRQ allocation bindings in rust/, yet we merged those. I think
that is reasonable. RFC should be used too when it makes sense, but I think we
should also look into merging things in chunks to avoid future review/rebase
burden. There isn't one rule that fits all is my point, right? I mean just look
at the attempted bitfield move too, Nova is the only user yet we will move it
out. But one may ask why move it out until there are other users? It has to be
on a case-by-case basis..

> - Other documentation patches belong to the series that introduces the
>   feature they document.
Agreed with the splitting suggestions, I will split this series moving forward.
But I may still push for merging small patches where it makes sense, if that's
Ok with everyone.

(I do feel the PRAMIN and GSP patch both do fall under the 'small patch' category)

thanks,

 - Joel

On Thu Oct 23, 2025 at 6:30 AM JST, Joel Fernandes wrote:
>> - The falcon interrupts patch does not seem to be used by the last two
>>   patches? I guess it belongs to the series that will add support for
>>   the interrupt controller.
> No, it is independent. Yes this leads up to the interrupt handing feature, but
> just to emphasize a bit, the motivation was to "get small patches" in so that we
> don't need to do obvious things later (example, the VFN interrupt module is much
> more complex than this GSP patch yet both are needed for interrupt handling, so
> the GSP patch is a good candidate IMO for upstreaming in the next merge window).
> Having small patches merged reduces future burden on both reviewers and the
> developers. This is also not something new, for instance we don't have any users
> of the PCI MSI IRQ allocation bindings in rust/, yet we merged those. I think
> that is reasonable. RFC should be used too when it makes sense, but I think we
> should also look into merging things in chunks to avoid future review/rebase
> burden. There isn't one rule that fits all is my point, right? I mean just look
> at the attempted bitfield move too, Nova is the only user yet we will move it
> out. But one may ask why move it out until there are other users? It has to be
> on a case-by-case basis..

We do have another user for bitfield/register and that's Tyr - the move
is to allow them to use these macros.

I am also more comfortable merging code when I understand how it is
called and used in practice. It doesn't necessarily need to be fully
complete, but something at least in RFC status demonstrating a real use
of the API helps.

Once a core patch in RFC status is reviewed and agreed on, it can be
added (with all the Reviewed-by tags) to the series containing its user
code, even if the user code comes later. It delays the merging of the
core code a bit, but since it has no user it would be dead merged code
anyway, and when you look at the whole picture it really comes down to
the same - there is no delay to when the machinery starts moving to
produce something useful.

Exceptions can be discussed if e.g. there is a big risk that a
refactoring will wreck everything, but this doesn't appear to be a
factor here.