Nouveau - Sep 2025 - [PATCH v2 01/10] gpu: nova-core: Set correct DMA mask

On Tue Sep 23, 2025 at 6:29 AM CEST, Alistair Popple
wrote:
> On 2025-09-23 at 12:16 +1000, John Hubbard <jhubbard at nvidia.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 mean, sure. But isn't the limitation of 47 bits coming from the MMU and
hence
defines the VA space width and the DMA bit width we can support?
> 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
>>

On 2025-09-26 at 22:00 +1000, Danilo Krummrich <dakr at kernel.org>
wrote...
> On Tue Sep 23, 2025 at 6:29 AM CEST, Alistair Popple wrote:
> > On 2025-09-23 at 12:16 +1000, John Hubbard <jhubbard at
nvidia.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 mean, sure. But isn't the limitation of 47 bits coming from the MMU
and hence
> defines the VA space width and the DMA bit width we can support?
Not at all. The 47 bit limitation comes from what the DMA engines can physically
address, whilst the MMU converts virtual addresses to physical DMA addresses.
So the two address spaces are different and can have different widths. Indeed
most of our current GPUs have a virtual address space of 49 bits whilst only
supporting 47 bits of DMA 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
> >> 
>