From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Alistair Popple" <apopple@nvidia.com>,
<rust-for-linux@vger.kernel.org>,
<dri-devel@lists.freedesktop.org>, <dakr@kernel.org>,
<acourbot@nvidia.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <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>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
linux-kernel@vger.kernel.org, nouveau@lists.freedesktop.org
Subject: Re: [PATCH v2 02/10] gpu: nova-core: Create initial Gsp
Date: Tue, 23 Sep 2025 23:20:37 +0900 [thread overview]
Message-ID: <DD08VDPA45X8.2VXMD1RJBAJER@nvidia.com> (raw)
In-Reply-To: <20250922113026.3083103-3-apopple@nvidia.com>
Hi Alistair,
On Mon Sep 22, 2025 at 8:30 PM JST, Alistair Popple wrote:
> The GSP requires several areas of memory to operate. Each of these have
> their own simple embedded page tables. Set these up and map them for DMA
> to/from GSP using CoherentAllocation's. Return the DMA handle describing
> where each of these regions are for future use when booting GSP.
>
> Signed-off-by: Alistair Popple <apopple@nvidia.com>
>
> ---
>
> Changes for v2:
>
> - Renamed GspMemOjbects to Gsp as that is what they are
> - Rebased on Alex's latest series
> ---
> drivers/gpu/nova-core/gpu.rs | 2 +-
> drivers/gpu/nova-core/gsp.rs | 80 +++++++++++++++++--
> drivers/gpu/nova-core/gsp/fw.rs | 39 +++++++++
> .../gpu/nova-core/gsp/fw/r570_144/bindings.rs | 19 +++++
> 4 files changed, 131 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
> index 5da9ad726483..c939b3868271 100644
> --- a/drivers/gpu/nova-core/gpu.rs
> +++ b/drivers/gpu/nova-core/gpu.rs
> @@ -221,7 +221,7 @@ pub(crate) fn new<'a>(
>
> sec2_falcon: Falcon::new(pdev.as_ref(), spec.chipset, bar, true)?,
>
> - gsp <- Gsp::new(),
> + gsp <- Gsp::new(pdev)?,
>
> _: { gsp.boot(pdev, bar, spec.chipset, gsp_falcon, sec2_falcon)? },
>
> diff --git a/drivers/gpu/nova-core/gsp.rs b/drivers/gpu/nova-core/gsp.rs
> index 503ce8ee0420..0185f66971ff 100644
> --- a/drivers/gpu/nova-core/gsp.rs
> +++ b/drivers/gpu/nova-core/gsp.rs
> @@ -1,27 +1,91 @@
> // SPDX-License-Identifier: GPL-2.0
>
> mod boot;
> -
> -use kernel::prelude::*;
> -
Oops, not sure why I put that here but thanks for fixing this.
> mod fw;
>
> pub(crate) use fw::{GspFwWprMeta, LibosParams};
>
> +use kernel::device;
> +use kernel::dma::CoherentAllocation;
> +use kernel::dma_write;
> +use kernel::pci;
> +use kernel::prelude::*;
> use kernel::ptr::Alignment;
> +use kernel::transmute::{AsBytes, FromBytes};
> +
> +use fw::LibosMemoryRegionInitArgument;
>
> pub(crate) const GSP_PAGE_SHIFT: usize = 12;
> pub(crate) const GSP_PAGE_SIZE: usize = 1 << GSP_PAGE_SHIFT;
> pub(crate) const GSP_HEAP_ALIGNMENT: Alignment = Alignment::new::<{ 1 << 20 }>();
>
> /// GSP runtime data.
> -///
> -/// This is an empty pinned placeholder for now.
> #[pin_data]
> -pub(crate) struct Gsp {}
> +pub(crate) struct Gsp {
> + libos: CoherentAllocation<LibosMemoryRegionInitArgument>,
> + pub loginit: CoherentAllocation<u8>,
> + pub logintr: CoherentAllocation<u8>,
> + pub logrm: CoherentAllocation<u8>,
These don't need to be public for now.
> +}
> +
> +/// Creates a self-mapping page table for `obj` at its beginning.
> +fn create_pte_array(obj: &mut CoherentAllocation<u8>) {
> + let num_pages = obj.size().div_ceil(GSP_PAGE_SIZE);
> + let handle = obj.dma_handle();
> +
> + // SAFETY:
> + // - By the invariants of the CoherentAllocation ptr is non-NULL.
> + // - CoherentAllocation CPU addresses are always aligned to a
> + // page-boundary, satisfying the alignment requirements for
> + // from_raw_parts_mut()
> + // - The allocation size is at least as long as 8 * num_pages as
> + // GSP_PAGE_SIZE is larger than 8 bytes.
> + let ptes = unsafe {
> + let ptr = obj.start_ptr_mut().cast::<u64>().add(1);
> + core::slice::from_raw_parts_mut(ptr, num_pages)
> + };
I think we also need to provide the same guarantees as
`CoherentAllocation::as_slice_mut`:
* Callers must ensure that the device does not read/write to/from memory
while the returned slice is live.
* Callers must ensure that this call does not race with a read or write
to the same region while the returned slice is live.
Unfortunately I don't think these are covered by this function alone -
it could perfectly be called on an allocation that is currently in use
by the hardware. So technically `create_pte_arrays` in its present form
should be unsafe, but that also would be overkill here since it is a
local function and we control the conditions into which it is called.
This PTE business, where we are taking any coherent allocation and
reinterpreting its bytes to create a page table, does not look very
clean to me anyway, so maybe we can solve this with a redesign. I'd
rather have that part of the object explicitly laid out, as it is for
`GspMem` later in this series (albeit with `u8` instead of `u64`):
struct GspMem {
ptes: [u8; GSP_PAGE_SIZE],
...
What would work best here IMHO would be to have a dedicated type for the
array of PTEs, which is placed at the beginning of each object
requesting one. Then we could have an init generic method for it that
takes a reference to any object and `dma_write!`s its entries, avoiding
the slice and having a guarantee that we have exclusive access to the
object since we just created it one line above. I need to think a bit
more about this but this should be a solid basis.
As it happens, loginit, logintr and logrm all have the same size, so we
should be able to declare a new type for these 3.
> +
> + for (i, pte) in ptes.iter_mut().enumerate() {
> + *pte = handle + ((i as u64) << GSP_PAGE_SHIFT);
> + }
> +}
> +
> +/// Creates a new `CoherentAllocation<A>` with `name` of `size` elements, and
> +/// register it into the `libos` object at argument position `libos_arg_nr`.
> +fn create_coherent_dma_object<A: AsBytes + FromBytes>(
> + dev: &device::Device<device::Bound>,
> + name: &'static str,
> + size: usize,
> + libos: &mut CoherentAllocation<LibosMemoryRegionInitArgument>,
> + libos_arg_nr: usize,
> +) -> Result<CoherentAllocation<A>> {
> + let obj = CoherentAllocation::<A>::alloc_coherent(dev, size, GFP_KERNEL | __GFP_ZERO)?;
> +
> + dma_write!(libos[libos_arg_nr] = LibosMemoryRegionInitArgument::new(name, &obj))?;
Once we have a dedicated type for DMA objects with PTEs, I suggest to
move this `dma_write` outside of this function. It doesn't bring any
value to have it here, and that way we can remove
`create_coherent_dma_object` altogether. Let me clarify below.
> +
> + Ok(obj)
> +}
>
> impl Gsp {
> - pub(crate) fn new() -> impl PinInit<Self> {
> - pin_init!(Self {})
> + pub(crate) fn new(pdev: &pci::Device<device::Bound>) -> Result<impl PinInit<Self, Error>> {
> + let dev = pdev.as_ref();
> + let mut libos = CoherentAllocation::<LibosMemoryRegionInitArgument>::alloc_coherent(
> + dev,
> + GSP_PAGE_SIZE / size_of::<LibosMemoryRegionInitArgument>(),
> + GFP_KERNEL | __GFP_ZERO,
> + )?;
> + let mut loginit = create_coherent_dma_object::<u8>(dev, "LOGINIT", 0x10000, &mut libos, 0)?;
> + create_pte_array(&mut loginit);
> + let mut logintr = create_coherent_dma_object::<u8>(dev, "LOGINTR", 0x10000, &mut libos, 1)?;
> + create_pte_array(&mut logintr);
> + let mut logrm = create_coherent_dma_object::<u8>(dev, "LOGRM", 0x10000, &mut libos, 2)?;
> + create_pte_array(&mut logrm);
So with the proper PTE-prefixed type, this code would become:
let loginit = PteDmaObject::new(dev)?;
let logintr = PteDmaObject::new(dev)?;
let logrm = PteDmaObject::new(dev)?;
dma_write!(libos[0] = LibosMemoryRegionInitArgument::new("LOGINIT", &loginit))?;
dma_write!(libos[1] = LibosMemoryRegionInitArgument::new("LOGINTR", &logintr))?;
dma_write!(libos[2] = LibosMemoryRegionInitArgument::new("LOGRM", &logrm))?;
Note how loginit and friends now don't need to be mutable anymore.
It's getting late here so let me continue the review tomorrow. :)
next prev parent reply other threads:[~2025-09-23 14:20 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-22 11:30 [PATCH v2 00/11] gpu: nova-core: Boot GSP to RISC-V active Alistair Popple
2025-09-22 11:30 ` [PATCH v2 01/10] gpu: nova-core: Set correct DMA mask Alistair Popple
2025-09-22 15:25 ` Boqun Feng
2025-09-22 16:08 ` Danilo Krummrich
2025-09-23 2:16 ` John Hubbard
2025-09-23 4:29 ` Alistair Popple
2025-09-26 12:00 ` Danilo Krummrich
2025-09-29 0:19 ` Alistair Popple
2025-09-29 7:06 ` Danilo Krummrich
2025-09-29 7:39 ` Alistair Popple
2025-09-29 12:49 ` Danilo Krummrich
2025-10-01 1:31 ` [PATCH v2 01/10] gpu: nova-core: Set correct DMA mask^[ Alistair Popple
2025-09-24 19:43 ` [PATCH v2 01/10] gpu: nova-core: Set correct DMA mask Lyude Paul
2025-09-22 11:30 ` [PATCH v2 02/10] gpu: nova-core: Create initial Gsp Alistair Popple
2025-09-23 14:20 ` Alexandre Courbot [this message]
2025-09-24 20:13 ` Lyude Paul
2025-09-24 20:50 ` John Hubbard
2025-09-24 21:07 ` Lyude Paul
2025-09-24 21:15 ` John Hubbard
2025-09-22 11:30 ` [PATCH v2 03/10] gpu: nova-core: gsp: Create wpr metadata Alistair Popple
2025-09-24 20:24 ` Lyude Paul
2025-09-26 1:24 ` Alexandre Courbot
2025-09-29 0:29 ` Alistair Popple
2025-09-29 14:54 ` Alexandre Courbot
2025-09-26 1:24 ` Alexandre Courbot
2025-09-29 0:38 ` Alistair Popple
2025-09-22 11:30 ` [PATCH v2 04/10] gpu: nova-core: Add a slice-buffer (sbuffer) datastructure Alistair Popple
2025-09-24 20:36 ` Lyude Paul
2025-09-29 0:44 ` Alistair Popple
2025-09-22 11:30 ` [PATCH v2 05/10] gpu: nova-core: gsp: Add GSP command queue handling Alistair Popple
2025-09-22 19:16 ` Timur Tabi
2025-09-24 22:03 ` Lyude Paul
2025-09-25 6:32 ` Alistair Popple
2025-09-26 2:20 ` Alexandre Courbot
2025-09-29 1:06 ` Alistair Popple
2025-09-29 7:24 ` Danilo Krummrich
2025-09-26 4:37 ` Alexandre Courbot
2025-09-29 6:19 ` Alistair Popple
2025-09-29 14:34 ` Alexandre Courbot
2025-09-29 14:38 ` Miguel Ojeda
2025-09-29 14:45 ` Alexandre Courbot
2025-09-30 11:41 ` Alistair Popple
2025-09-30 11:58 ` Miguel Ojeda
2025-10-01 0:42 ` Alistair Popple
2025-09-30 0:36 ` Alistair Popple
2025-09-30 10:33 ` Danilo Krummrich
2025-09-30 13:36 ` Alexandre Courbot
2025-09-22 11:30 ` [PATCH v2 06/10] gpu: nova-core: gsp: Create rmargs Alistair Popple
2025-09-24 22:05 ` Lyude Paul
2025-09-26 7:27 ` Alexandre Courbot
2025-09-29 6:36 ` Alistair Popple
2025-09-29 7:18 ` Danilo Krummrich
2025-09-29 7:49 ` Alistair Popple
2025-09-22 11:30 ` [PATCH v2 07/10] gpu: nova-core: gsp: Create RM registry and sysinfo commands Alistair Popple
2025-09-22 19:10 ` Timur Tabi
2025-09-23 4:40 ` Alistair Popple
2025-09-23 4:46 ` Timur Tabi
2025-09-24 22:11 ` Lyude Paul
2025-09-22 11:30 ` [PATCH v2 08/10] nova-core: falcon: Add support to check if RISC-V is active Alistair Popple
2025-09-22 19:12 ` Timur Tabi
2025-09-23 1:07 ` John Hubbard
2025-09-23 4:23 ` Timur Tabi
2025-09-23 4:42 ` Alistair Popple
2025-09-24 22:12 ` Lyude Paul
2025-09-22 11:30 ` [PATCH v2 09/10] nova-core: falcon: Add support to write firmware version Alistair Popple
2025-09-24 22:14 ` Lyude Paul
2025-09-22 11:30 ` [PATCH v2 10/10] nova-core: gsp: Boot GSP Alistair Popple
2025-09-24 22:15 ` Lyude Paul
2025-09-24 22:24 ` John Hubbard
2025-09-25 3:09 ` Timur Tabi
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=DD08VDPA45X8.2VXMD1RJBAJER@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--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=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--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