public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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. :)

  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