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

["Alexandre Courbot" <acourbot@nvidia.com>]

On Tue Jun 2, 2026 at 12:30 PM JST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Hardware match requirement violation during sysmem flush configuration on GB10x.
> --
>
> commit 4c62a61ec72a7cc29b5d20a82279ea5490f2e759
> Author: John Hubbard <jhubbard@nvidia.com>
>
> gpu: nova-core: Blackwell: use correct sysmem flush registers
>
> This commit updates the Blackwell GPUs to route the sysmem flush page
> registers to their proper locations. It defines the registers relative to
> HSHUB0 for GB10x and FBHUB0 for GB20x, and implements the flush paths in
> their respective HALs.
>
>> diff --git a/drivers/gpu/nova-core/fb/hal/gb100.rs b/drivers/gpu/nova-core/fb/hal/gb100.rs
>> index 8d63350abf8aa..ecea4ff446fff 100644
>> --- a/drivers/gpu/nova-core/fb/hal/gb100.rs
>> +++ b/drivers/gpu/nova-core/fb/hal/gb100.rs
>
> [ ... ]
>
>> +/// Write the sysmem flush page address through the GB10x HSHUB0 registers.
>> +///
>> +/// Both the primary and EG (egress) register pairs must be programmed to the same address,
>> +/// as required by hardware.
>> +fn write_sysmem_flush_page_gb100(bar: &Bar0, addr: Bounded<u64, 52>) {
>> +    // CAST: lower 32 bits. Hardware ignores bits 7:0.
>> +    let addr_lo = *addr as u32;
>> +    let addr_hi = addr.shr::<32, 20>().cast::<u32>();
>> +
>> +    // Write HI first. The hardware will trigger the flush on the LO write.
>> +
>> +    // Primary HSHUB pair.
>> +    bar.write(
>> +        regs::NV_PFB_HSHUB_PCIE_FLUSH_SYSMEM_ADDR_HI::of::<Gb100>(),
>> +        regs::NV_PFB_HSHUB_PCIE_FLUSH_SYSMEM_ADDR_HI::zeroed().with_adr(addr_hi),
>> +    );
>> +    bar.write(
>> +        regs::NV_PFB_HSHUB_PCIE_FLUSH_SYSMEM_ADDR_LO::of::<Gb100>(),
>> +        regs::NV_PFB_HSHUB_PCIE_FLUSH_SYSMEM_ADDR_LO::zeroed().with_adr(addr_lo),
>> +    );
>
> [Severity: High]
> Does writing the primary LO register here trigger the flush before the EG
> registers are updated to match?
>
> The comments state that the hardware triggers the flush on the LO write, and
> that both the primary and EG pairs must be programmed to the same address.
> Because the EG pair is written after this primary LO register write, could
> the hardware perform the flush while the EG registers still contain their old,
> mismatched address?

After confirmation the sequence is identical to OpenRM's, so this
particular concern does not look valid.