Re: [PATCH v11 06/22] gpu: nova-core: Blackwell: use correct sysmem flush registers

[Alexandre Courbot]

On Sat May 30, 2026 at 12:09 PM JST, John Hubbard wrote:
<snip>
> diff --git a/drivers/gpu/nova-core/regs.rs b/drivers/gpu/nova-core/regs.rs
> index 356fbf364ea5..65be6ec71ed4 100644
> --- a/drivers/gpu/nova-core/regs.rs
> +++ b/drivers/gpu/nova-core/regs.rs
> @@ -1,4 +1,5 @@
>  // SPDX-License-Identifier: GPL-2.0
> +// SPDX-FileCopyrightText: Copyright (c) 2025-2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
>  
>  use kernel::{
>      io::{
> @@ -145,6 +146,42 @@ fn fmt(&self, f: &mut kernel::fmt::Formatter<'_>) -> kernel::fmt::Result {
>          /// Bits 12..40 of the higher (exclusive) bound of the WPR2 region.
>          31:4    hi_val;
>      }
> +
> +    // Blackwell GB10x sysmem flush registers (HSHUB0).
> +    //
> +    // GB10x GPUs use two pairs of HSHUB registers for sysmembar: a primary pair and an EG
> +    // (egress) pair. Both must be programmed to the same address. Hardware ignores bits 7:0
> +    // of each LO register. HSHUB0 base is 0x00891000.
> +
> +    pub(crate) NV_PFB_HSHUB0_PCIE_FLUSH_SYSMEM_ADDR_LO(u32) @ 0x00891e50 {
> +        31:0    adr => u32;
> +    }
> +
> +    pub(crate) NV_PFB_HSHUB0_PCIE_FLUSH_SYSMEM_ADDR_HI(u32) @ 0x00891e54 {
> +        19:0    adr;
> +    }
> +
> +    pub(crate) NV_PFB_HSHUB0_EG_PCIE_FLUSH_SYSMEM_ADDR_LO(u32) @ 0x008916c0 {
> +        31:0    adr => u32;
> +    }
> +
> +    pub(crate) NV_PFB_HSHUB0_EG_PCIE_FLUSH_SYSMEM_ADDR_HI(u32) @ 0x008916c4 {
> +        19:0    adr;
> +    }

I am still a bit uncertain about the addresses of these registers.
OpenRM seems to use `0x00870000` as the base [1][2] and use relative
offsets from it; that would make the address of e.g. `SYSMEM_ADDR_LO` be
`0x00870e500`. I cannot find any reference to a `0x00891000` base. Can
you double-check where it comes from?

Ideally these should also be relative registers with the same names as
OpenRM (e.g. `NV_PFB_HSHUB_PCIE_FLUSH_SYSMEM_ADDR_LO`) for easy lookup.
The `Hshub0` base can be declared in the `gb100` HAL since it's the only
place that uses it for now.

As I mentioned in my v10 review [3], there is more complexity to the
HSHUB module that involves runtime-detected values, but for boot it
looks like it also does rely on HSHUB0 as a stable base, so thankfully
we don't have to worry about this for now.

[1] https://github.com/NVIDIA/open-gpu-kernel-modules/blob/570.148/src/nvidia/src/kernel/gpu/mem_sys/arch/blackwell/kern_mem_sys_gb100.c#L54
[2] https://github.com/NVIDIA/open-gpu-kernel-modules/blob/570.148/src/common/inc/swref/published/blackwell/gb100/dev_hshub_base.h
[3] https://lore.kernel.org/all/DHY1D4IOXGRF.UQMCOXYG78CZ@xxxxxxxxxx/