From: John Hubbard <jhubbard@nvidia.com>
To: Alexandre Courbot <acourbot@nvidia.com>,
Danilo Krummrich <dakr@kernel.org>,
Alice Ryhl <aliceryhl@google.com>,
David Airlie <airlied@gmail.com>, Gary Guo <gary@garyguo.net>,
Simona Vetter <simona@ffwll.ch>
Cc: Alistair Popple <apopple@nvidia.com>,
Timur Tabi <ttabi@nvidia.com>,
Eliot Courtney <ecourtney@nvidia.com>, Zhi Wang <zhiw@nvidia.com>,
nova-gpu@lists.linux.dev, dri-devel@lists.freedesktop.org,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] gpu: nova-core: falcon: use I/O projection to check transfer bounds
Date: Fri, 24 Jul 2026 11:10:38 -0700 [thread overview]
Message-ID: <e7ba2c90-6d4f-487e-bd25-56d568ba1f26@nvidia.com> (raw)
In-Reply-To: <20260724-falcon-dma-projections-v1-2-957028a7c0a7@nvidia.com>
On 7/24/26 4:10 AM, Alexandre Courbot wrote:
> The DMA transfer routine was computing the start of the DMA area by
> taking the handle to the beginning of the coherent allocation, and then
> adding the transfer's start offset. It then checked manually that the
> upper bound was valid.
>
> Convert this to an I/O projection of the same region, which returns
> `ERANGE` if the passed range does not fit within the coherent
> allocation. This removes the need to perform arithmetic on DMA handles
> and to explicitly check for the bounds' validity.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> drivers/gpu/nova-core/falcon.rs | 55 +++++++++++++++++------------------------
> 1 file changed, 23 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/falcon.rs b/drivers/gpu/nova-core/falcon.rs
> index cd05985f5ee6..344cb1487295 100644
> --- a/drivers/gpu/nova-core/falcon.rs
> +++ b/drivers/gpu/nova-core/falcon.rs
> @@ -12,6 +12,7 @@
> DmaAddress, //
> },
> io::{
> + io_project,
> poll::read_poll_timeout,
> register::{
> RegisterBase,
> @@ -511,20 +512,31 @@ fn dma_wr(
> ) -> Result {
> const DMA_LEN: u32 = num::usize_into_u32::<{ MEM_BLOCK_ALIGNMENT }>();
>
> + // DMA transfers can only be done in units of 256 bytes. Compute how many such transfers we
> + // need to perform.
> + let num_transfers = load_offsets.len.div_ceil(DMA_LEN);
> +
> // For IMEM, we want to use the start offset as a virtual address tag for each page, since
> // code addresses in the firmware (and the boot vector) are virtual.
> //
> - // For DMEM we can fold the start offset into the DMA handle.
> + // For DMEM, the start offset is folded into the DMA address.
> let (src_start, dma_start) = match target_mem {
> - FalconMem::ImemSecure | FalconMem::ImemNonSecure => {
> - (load_offsets.src_start, dma_obj.dma_handle())
> - }
> - FalconMem::Dmem => (
> - 0,
> - dma_obj.dma_handle() + DmaAddress::from(load_offsets.src_start),
> - ),
> + FalconMem::ImemSecure | FalconMem::ImemNonSecure => (load_offsets.src_start, 0),
> + FalconMem::Dmem => (0, usize::from_safe_cast(load_offsets.src_start)),
> };
> - if dma_start % DmaAddress::from(DMA_LEN) > 0 {
> +
> + let dma_handle = {
Sort of "conceptually pre-existing" problem, but "handle" doesn't
quite work as a name, because handles are supposed to be opaque
items that one just uses to find and refer to things.
And below, that is violated:
> + // Upper limit of transfer is `(num_transfers * DMA_LEN) + load_offsets.src_start`.
> + let dma_end = num_transfers
> + .checked_mul(DMA_LEN)
> + .and_then(|size| size.checked_add(load_offsets.src_start))
> + .map(usize::from_safe_cast)
> + .ok_or(EOVERFLOW)?;
> +
> + io_project!(dma_obj, [try: dma_start..dma_end]).dma_handle()
> + };
> +
> + if dma_handle % DmaAddress::from(DMA_LEN) > 0 {
> dev_err!(
> self.dev,
> "DMA transfer start addresses must be a multiple of {}\n",
> @@ -533,27 +545,6 @@ fn dma_wr(
> return Err(EINVAL);
> }
>
> - // DMA transfers can only be done in units of 256 bytes. Compute how many such transfers we
> - // need to perform.
> - let num_transfers = load_offsets.len.div_ceil(DMA_LEN);
> -
> - // Check that the area we are about to transfer is within the bounds of the DMA object.
> - // Upper limit of transfer is `(num_transfers * DMA_LEN) + load_offsets.src_start`.
> - match num_transfers
> - .checked_mul(DMA_LEN)
> - .and_then(|size| size.checked_add(load_offsets.src_start))
> - {
> - None => {
> - dev_err!(self.dev, "DMA transfer length overflow\n");
> - return Err(EOVERFLOW);
> - }
> - Some(upper_bound) if usize::from_safe_cast(upper_bound) > dma_obj.size() => {
> - dev_err!(self.dev, "DMA transfer goes beyond range of DMA object\n");
> - return Err(EINVAL);
> - }
> - Some(_) => (),
> - };
> -
> // Set up the base source DMA address.
>
> self.bar.write(
> @@ -561,12 +552,12 @@ fn dma_wr(
> regs::NV_PFALCON_FALCON_DMATRFBASE::zeroed().with_base(
> // CAST: `as u32` is used on purpose since we do want to strip the upper bits,
> // which will be written to `NV_PFALCON_FALCON_DMATRFBASE1`.
> - (dma_start >> 8) as u32,
> + (dma_handle >> 8) as u32,
This is a "whaaat?" moment: shifting dma_start makes sense,
but shifting a handle does not.
Thoughts?
thanks,
--
John Hubbard
next prev parent reply other threads:[~2026-07-24 18:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 11:10 [PATCH 0/2] gpu: nova-core: falcon: use I/O projections for DMA transfers Alexandre Courbot
2026-07-24 11:10 ` [PATCH 1/2] gpu: nova-core: falcon: remove unnecessary check Alexandre Courbot
2026-07-24 11:10 ` [PATCH 2/2] gpu: nova-core: falcon: use I/O projection to check transfer bounds Alexandre Courbot
2026-07-24 18:10 ` John Hubbard [this message]
2026-07-24 22:27 ` Danilo Krummrich
2026-07-25 4:42 ` Alexandre Courbot
2026-07-25 14:55 ` Danilo Krummrich
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=e7ba2c90-6d4f-487e-bd25-56d568ba1f26@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=ttabi@nvidia.com \
--cc=zhiw@nvidia.com \
/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