From: Joel Fernandes <joelagnelf@nvidia.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
dri-devel@lists.freedesktop.org, dakr@kernel.org,
acourbot@nvidia.com, Alistair Popple <apopple@nvidia.com>,
Miguel Ojeda <ojeda@kernel.org>,
Alex Gaynor <alex.gaynor@gmail.com>,
Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>,
bjorn3_gh@protonmail.com, Benno Lossin <lossin@kernel.org>,
Andreas Hindborg <a.hindborg@kernel.org>,
Alice Ryhl <aliceryhl@google.com>,
Trevor Gross <tmgross@umich.edu>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
John Hubbard <jhubbard@nvidia.com>, Timur Tabi <ttabi@nvidia.com>,
joel@joelfernandes.org, Elle Rhumsaa <elle@weathered-steel.dev>,
Daniel Almeida <daniel.almeida@collabora.com>,
nouveau@lists.freedesktop.org
Subject: Re: [PATCH 7/7] nova-core: mm: Add data structures for page table management
Date: Mon, 3 Nov 2025 14:21:26 -0500 [thread overview]
Message-ID: <226d7dcb-26c3-4477-b1e9-2b837dc17cd1@nvidia.com> (raw)
In-Reply-To: <CANiq72=SSQ5nSjt9yzX_A3Tgo2ByGM5CV0VqFnF1cTOzrZ-pbg@mail.gmail.com>
Hi Miguel,
On 10/20/2025 5:30 PM, Miguel Ojeda wrote:
> Hi Joel,
>
> A few nits below (I do sometimes this kind of docs review to try to
> keep a consistent style across all Rust code).
Thanks a lot for these, I studied all of the suggestions and agree with them.
May I also suggest to add some of these suggestions to the kernel rust coding
guidelines document, that way others new to sending rust kernel patches don't
miss it (example not adding a period at the end of a markdown doc header.). But
I will make it a point to check all my patches to make sure it confirms to the
suggestions.
Also a lot of your suggestions are related to how it looks it rustdoc, so I will
try to build rustdoc and see what it looks like as well, to get an idea of when
things in my patches could be improved.
thanks,
- Joel
>
> On Mon, Oct 20, 2025 at 8:56 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>>
>> +//! .set_table_frame_number(new_table.frame_number());
>> +//! // Call a function to write PDE to VRAM address
>
> Newline between these. Period ad the end.
>
>> +//! ## Given a PTE, Get or allocate a PFN (page frame number).
>
> In headers, no period at the end. Also, is "Get" intended to be capitalized?
>
>> +//! // Call a function to read 64-bit PTE value from VRAM address
>
> Period at the end too (more of these elsewhere).
>
>> +//! if pte.valid() {
>> +//! // Return physical frame number from existing mapping
>> +//! Ok(Pfn::new(pte.frame_number()))
>
> Early returns where possible, like in C, i.e. to avoid indentation on
> big `else` branches.
>
>> +/// Memory size constants
>> +pub(crate) const KB: usize = 1024;
>> +pub(crate) const MB: usize = KB * 1024;
>
> The docs will only apply to the first item, so this probably was meant
> to be a `//` instead of a `///`.
>
> Or you could use a module to contain these (and then possibly `use`
> them outside), and then you can have docs in the module itself, but
> that is heavier.
>
>> +/// Page size: 4 KiB
>> +pub(crate) const PAGE_SIZE: usize = 4 * KB;
>
> `rustdoc` would eventually render the value and the non-evaluated
> expression, and in the source code it already says `4 * KB`, so I
> think repeating the value isn't needed, unless you mean to show it is
> really a multiple of 2.
>
>> +pub(crate) enum PageTableLevel {
>> + Pdb, // Level 0 - Page Directory Base
>> + L1, // Level 1
>> + L2, // Level 2
>> + L3, // Level 3 - Dual PDE (128-bit entries)
>> + L4, // Level 4 - PTEs
>
> In this case, I think you meant the other way around, i.e. actual
> docs: `///` instead of `//`.
>
> (Also, unless there is a particular reason (e.g. it is a big table),
> please generally put comments on top of things, not at the side, which
> matches closer to what is needed for docs.)
>
>> + /// Convert an Address to a frame number.
>
> These should eventually be intra-doc links, but at least please use
> for the moment backticks when referring to Rust items like types etc.
>
>> + /// # Example
>
> We always use the plural for these section headers, even if there is a
> single item (e.g. single example).
>
>> + /// ```no_run
>> + /// let va = VirtualAddress::default();
>> + /// let pte_idx = va.level_index(PageTableLevel::L4);
>> + /// ```
>
> This will need some `use` lines -- not needed now, but just as a
> reminder that these will get actually built eventually.
>
>> + /// Get raw u64 value.
>
> Intra-doc link or at least backticks.
>
>> + /// The valid bit is inverted so add an accessor to flip it.
>> + pub(crate) fn set_valid(&self, value: bool) -> Pde {
>
> This docs string sounds like a commit message.
>
>> +/// Dual PDE at Level 3 - 128-bit entry containing both LPT and SPT pointers.
>> +/// Lower 64 bits = big/large page, upper 64 bits = small page.
>
> It sounds like a few of these details should be on its own paragraph
> to avoid having them in the short description (title).
>
>> +/// // Call a function to read dual PDE from VRAM address
>> +/// let mut dual_pde: DualPde = read_dual_pde(dpde_addr)?;
>> +/// // Call a function to allocate a page table and return its VRAM address
>> +/// let spt_addr = allocate_page_table()?;
>> +/// dual_pde.set_spt(Pfn::from(spt_addr), AperturePde::VideoMemory);
>> +/// // Call a function to write dual PDE to VRAM address
>> +/// write_dual_pde(dpde_addr, dual_pde)?;
>
> Newlines before the comments, i.e. between "conceptual blocks".
>
>> + pub lpt: Pde, // Large/Big Page Table pointer (2MB pages) - bits 63:0 (lower)
>> + pub spt: Pde, // Small Page Table pointer (4KB pages) - bits 127:64 (upper)
>
> Docs instead of comments.
>
>> + /// Check if has valid Small Page Table.
>
> Missing word?
>
> Thanks!
>
> Cheers,
> Miguel
next prev parent reply other threads:[~2025-11-03 19:21 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-20 18:55 [PATCH 0/7] Pre-requisite patches for mm and irq in nova-core Joel Fernandes
2025-10-20 18:55 ` [PATCH 1/7] docs: rust: Fix a few grammatical errors Joel Fernandes
2025-10-20 21:21 ` John Hubbard
2025-10-20 21:33 ` Miguel Ojeda
2025-10-20 23:23 ` Joel Fernandes
2025-10-20 18:55 ` [PATCH 2/7] gpu: nova-core: Add support to convert bitfield to underlying type Joel Fernandes
2025-10-20 21:25 ` John Hubbard
2025-10-22 6:25 ` Alexandre Courbot
2025-10-22 17:51 ` Joel Fernandes
2025-10-20 18:55 ` [PATCH 3/7] docs: gpu: nova-core: Document GSP RPC message queue architecture Joel Fernandes
2025-10-20 21:49 ` John Hubbard
2025-10-22 1:43 ` Bagas Sanjaya
2025-10-22 11:16 ` Alexandre Courbot
2025-10-20 18:55 ` [PATCH 4/7] docs: gpu: nova-core: Document the PRAMIN aperture mechanism Joel Fernandes
2025-10-20 19:36 ` John Hubbard
2025-10-20 19:48 ` Joel Fernandes
2025-10-20 20:42 ` John Hubbard
2025-10-20 20:45 ` Joel Fernandes
2025-10-20 22:08 ` John Hubbard
2025-10-22 2:09 ` Bagas Sanjaya
2025-10-20 18:55 ` [PATCH 5/7] gpu: nova-core: Add support for managing GSP falcon interrupts Joel Fernandes
2025-10-20 22:35 ` John Hubbard
2025-10-21 18:42 ` Joel Fernandes
2025-10-22 6:48 ` Alexandre Courbot
2025-10-22 21:09 ` Joel Fernandes
2025-10-22 23:16 ` John Hubbard
2025-10-22 6:47 ` Alexandre Courbot
2025-10-22 21:05 ` Joel Fernandes
2025-10-20 18:55 ` [PATCH 6/7] nova-core: mm: Add support to use PRAMIN windows to write to VRAM Joel Fernandes
2025-10-22 2:18 ` John Hubbard
2025-10-22 17:48 ` Joel Fernandes
2025-10-22 20:43 ` Joel Fernandes
2025-10-24 11:31 ` Alexandre Courbot
2025-10-22 10:41 ` Alexandre Courbot
2025-10-22 22:04 ` Joel Fernandes
2025-10-24 11:39 ` Alexandre Courbot
2025-10-20 18:55 ` [PATCH 7/7] nova-core: mm: Add data structures for page table management Joel Fernandes
2025-10-20 20:59 ` John Hubbard
2025-10-21 18:26 ` Joel Fernandes
2025-10-21 20:30 ` John Hubbard
2025-10-21 21:58 ` Joel Fernandes
2025-10-20 21:30 ` Miguel Ojeda
2025-11-03 19:21 ` Joel Fernandes [this message]
2025-11-04 17:54 ` Miguel Ojeda
2025-11-04 18:18 ` Danilo Krummrich
2025-11-03 19:29 ` John Hubbard
2025-11-04 17:56 ` Miguel Ojeda
2025-11-05 2:25 ` John Hubbard
2025-10-22 11:21 ` Alexandre Courbot
2025-10-22 19:13 ` Joel Fernandes
2025-10-20 21:20 ` [PATCH 0/7] Pre-requisite patches for mm and irq in nova-core John Hubbard
2025-10-21 18:29 ` Joel Fernandes
2025-10-22 6:57 ` Alexandre Courbot
2025-10-22 21:30 ` Joel Fernandes
2025-10-24 11:51 ` Alexandre Courbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=226d7dcb-26c3-4477-b1e9-2b837dc17cd1@nvidia.com \
--to=joelagnelf@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=elle@weathered-steel.dev \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox