linux-kernel - Re: [PATCH v2 01/10] gpu: nova-core: Set correct DMA mask

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <eblaubjmsesi6gh64ekm74qyzvfk23vjcmotc33upkc5w6edin@rbsezy6f7bai>
Date: Tue, 23 Sep 2025 14:29:16 +1000
From: Alistair Popple <apopple@...dia.com>
To: John Hubbard <jhubbard@...dia.com>
Cc: Danilo Krummrich <dakr@...nel.org>, rust-for-linux@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, acourbot@...dia.com, Miguel Ojeda <ojeda@...nel.org>, 
	Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, 
	Trevor Gross <tmgross@...ch.edu>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, 
	Joel Fernandes <joelagnelf@...dia.com>, Timur Tabi <ttabi@...dia.com>, linux-kernel@...r.kernel.org, 
	nouveau@...ts.freedesktop.org
Subject: Re: [PATCH v2 01/10] gpu: nova-core: Set correct DMA mask

On 2025-09-23 at 12:16 +1000, John Hubbard <jhubbard@...dia.com> wrote...
> On 9/22/25 9:08 AM, Danilo Krummrich wrote:
> > On 9/22/25 1:30 PM, Alistair Popple wrote:
> >> +        // SAFETY: No DMA allocations have been made yet
> > 
> > It's not really about DMA allocations that have been made previously, there is
> > no unsafe behavior in that.
> > 
> > It's about the method must not be called concurrently with any DMA allocation or
> > mapping primitives.
> > 
> > Can you please adjust the comment correspondingly?

Sure.

> >> +        unsafe { pdev.dma_set_mask_and_coherent(DmaMask::new::<47>())? };
> > 
> > As Boqun mentioned, we shouldn't have a magic number for this. I don't know if
> > it will change for future chips, but maybe we should move this to gpu::Spec to
> 
> It changes to 52 bits for GH100+ (Hopper/Blackwell+). When I post those
> patches, I'll use a HAL to select the value.
> 
> > be safe.
> > 
> > At least, create a constant for it (also in gpu::Spec?); in Nouveau I named this
> > NOUVEAU_VA_SPACE_BITS back then. Not a great name, if you have a better idea,
> > please go for it. :)

Well it's certainly not the VA_SPACE width ... that's a different address space :-)

I thought from the context that the magic number was pretty obviously the
supported DMA address width in bits, especially given the extra decoration
of the DmaMask type. Certainly that's been the accepted practice for the rest
of the kernel where pretty much all drivers just use something of the form
dma_set_mask(drm_dev->dev, DMA_BIT_MASK(44)) or whatever DMA address widths
they support.

> GPU_DMA_BIT_WIDTH, for now?

Works for me.

> thanks,
> -- 
> John Hubbard
>