From: John Hubbard <jhubbard@nvidia.com>
To: Joel Fernandes <joelagnelf@nvidia.com>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
dri-devel@lists.freedesktop.org, dakr@kernel.org,
acourbot@nvidia.com
Cc: 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>,
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: Tue, 21 Oct 2025 13:30:33 -0700 [thread overview]
Message-ID: <fac90f9e-0389-41de-86b7-18b13832f413@nvidia.com> (raw)
In-Reply-To: <a4241841-b9cc-46ce-baa8-91545c2aa4ee@nvidia.com>
On 10/21/25 11:26 AM, Joel Fernandes wrote:
> On 10/20/2025 4:59 PM, John Hubbard wrote:
>> On 10/20/25 11:55 AM, Joel Fernandes wrote:
>> ...
> Yes, there's different format versions.
>
> This patch supports all Turing and later GPUs because all GPUs including Hopper+
> are backward compatible with version 1. However they wont be able to use the
> version 2 and 3 features with only this patch.
>
> I kind of intentionally did this for a first cut. But yes, I could split it into
> versions. The 3 MMU structures (PTE, PDE and Dual PDE) are versioned. Version 2
> is Turing and later. Hopper+ is when Version 3 got introduced and it is also
Ah, then we shouldn't even do version 1. We should take full advantage of
the fact that Nova's earliest GPU is Turing.
> backward compatible with Version 2.
>
> We could eventually support versions 2 and 3 (instead of just version 1 as I am
> doing), however my working MMU translation prototype is based on version 1 (I
> did not have to configure anything in the MMU to switch versions, this was default).
>
> There are a couple of options:
>
> 1. For starters, support only version 1. Drawback is, when/if we want to use
> version 2 and 3 features, it may require some rework.
>
> 2. Have the following hierarchy:
> mm/types.rs - all common structures (stuff that is generic like Pfn).
> mm/types/ver1.rs - Version 1 specific types.
> mm/types/ver2.rs - Version 2 specific types.
> mm/types/ver3.rs - Version 3 specific types.
Maybe a file/directory structure that more directly indicates page table
formats. "mm/types" could be quite a few things.
> The advantage of this is it keeps the structs namespaced. So it'd be
> nova_core::mm:types::ver2::Pte or nova_core::mm:types::ver3::Pte. And the
> nova-core MMU code can pick the correct version.
>
> 3. Keep the single file types.rs and just suffix the structs with version
> numbers. This is attractive because there are only 3 types that have version
> flavors (pte, pde and dual pde). So instead of Pte, we would have PteVersion1,
> PteVersion2 etc, and a helper abstraction can pick the correct struct.
>
> 4. Any of the options 1-3, but dropping version 1 since Turing+ supports version
> 2 and later. I do have to figure out how to configure the MMU to use a specific
Right, I see you already noticed that we can start with Turing. Good.
> version (which is reasonable).
>
> 5. Your options here.
>
> Btw, I used Nouveau as a reference as well, so likely Nouveau doesn't support
> version 2 and 3 features. Not that that matters (we should support newer
> features in nova-core), but just thought I'd mention it.
>
> Other thoughts?
Two things:
1) Danilo is working on writing down locking requirements for Nova page
tables, based on earlier experience with Nouveau page table locking
problems, which were apparently very serious.
2) Maybe it would be good to start with versions 2 and 3, so that we
can see how to do >1 version?
thanks,
--
John Hubbard
next prev parent reply other threads:[~2025-10-21 20:30 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 [this message]
2025-10-21 21:58 ` Joel Fernandes
2025-10-20 21:30 ` Miguel Ojeda
2025-11-03 19:21 ` Joel Fernandes
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=fac90f9e-0389-41de-86b7-18b13832f413@nvidia.com \
--to=jhubbard@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=joel@joelfernandes.org \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=maarten.lankhorst@linux.intel.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
Powered by JetHome