From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Alistair Popple" <apopple@nvidia.com>
Cc: "nova-gpu" <nova-gpu@lists.linux.dev>,
"Danilo Krummrich" <dakr@kernel.org>,
"John Hubbard" <jhubbard@nvidia.com>
Subject: Re: [PATCH] gpu: nova-core: Use bar1_resource_index() in NovaCoreApi::bar1_size()
Date: Sat, 03 Oct 2026 10:31:16 +0900 [thread overview]
Message-ID: <DLUTCLVNFV8M.1L7IXUA4W5AFO@nvidia.com> (raw)
In-Reply-To: <20261001005615.77130-1-apopple@nvidia.com>
On Thu Oct 1, 2026 at 9:56 AM JST, Alistair Popple wrote:
> bar1_size() reports the length of PCI resource 1 as the size of BAR1.
> That is only correct when BAR0 is a 32-bit BAR. On Blackwell, and on some
> Ampere GA100 and Hopper SKUs, BAR0 is 64-bit and takes resource slots 0
> and 1, pushing BAR1 to slot 2. Slot 1 is then the upper half of BAR0
> rather than a BAR of its own, so NOVA_GETPARAM_VRAM_BAR_SIZE reports the
> wrong size on those GPUs.
>
> Probe handles this with the new bar1_resource_index(), which it uses to
> map BAR1, so use the same lookup here.
>
> Fixes: 7edc491f6fca ("drm: nova: Use nova-core to read VRAM_BAR_SIZE parameter")
> Signed-off-by: Alistair Popple <apopple@nvidia.com>
>
> ---
>
> Danilo,
>
> Not sure how you want to take this, you could either take it as a
> standalone patch or fold it into my series as the pre-requisite change
> that introduced bar1_resource_index() 159427b21352 ("gpu: nova-core: mm:
> Add BAR1 user interface") comes before my series in drm-rust-next.
>
> - Alistair
> ---
> drivers/gpu/nova-core/api.rs | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/nova-core/api.rs b/drivers/gpu/nova-core/api.rs
> index f02c6c7c7e51..cc1d936b002c 100644
> --- a/drivers/gpu/nova-core/api.rs
> +++ b/drivers/gpu/nova-core/api.rs
> @@ -44,7 +44,9 @@ pub fn spec(&self) -> &Spec {
> /// Returns the size of the PCIe BAR used for accessing VRAM, typically
> /// BAR1.
> pub fn bar1_size(&self) -> Result<u64> {
> - self.pdev.resource_len(1)
> + let bar1 = crate::driver::bar1_resource_index(self.pdev)?;
> +
> + self.pdev.resource_len(bar1)
I guess at some point we will want an iterator on `pci::Device` that
returns a `BarInfo` type or something? Zhi has some similar logic in his
SR-IOV series (method `vf_bars` of [1]) and this seems to be a common
mistake code makes when iterating BARs.
Just an idea for a future patch, this one is of course correct.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
[1] https://lore.kernel.org/all/20260906060404.3336193-2-zhiw@nvidia.com/
next prev parent reply other threads:[~2026-10-03 1:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 0:56 [PATCH] gpu: nova-core: Use bar1_resource_index() in NovaCoreApi::bar1_size() Alistair Popple
2026-10-03 1:31 ` Alexandre Courbot [this message]
2026-10-05 19:54 ` 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=DLUTCLVNFV8M.1L7IXUA4W5AFO@nvidia.com \
--to=acourbot@nvidia.com \
--cc=apopple@nvidia.com \
--cc=dakr@kernel.org \
--cc=jhubbard@nvidia.com \
--cc=nova-gpu@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.