All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ilia Mirkin <imirkin@alum.mit.edu>
To: Joshua Bakita <jbakita@cs.unc.edu>
Cc: nouveau <nouveau@lists.freedesktop.org>
Subject: Re: [Nouveau] Understanding BAR1 Offset to imem/VRAM PA Mapping
Date: Thu, 30 Sep 2021 23:45:55 -0400	[thread overview]
Message-ID: <CAKb7UvhUQrbD8tpn=K3KBg4BycFh5zvKM+G0He4onu3dXnYdYw@mail.gmail.com> (raw)
In-Reply-To: <CAAy0SxCY_5jpsRnR+okQ1HgXE2frzPe98hNJ8Yrju-bMRDqLnQ@mail.gmail.com>

Hi Joshua,

It looks like you got most of the way there. The BARs (BAR1 and BAR3)
are initialized by the code in nvkm/subdev/bar/gf100.c. As you can
see, this sets up a vmm per BAR, whose (physical address >> 12) is
written to 0x1704 / 0x1714. A vmm is basically a list of PDE's (and
the PTE lists those PDE's point to). The address, I believe, is the
base of the PDE's (or maybe they start at 0x200 from the base
address). I believe that all addresses relative to the appropriate BAR
are then translated through this vmm and hit the appropriate physical
VRAM addresses. You can see how this is all set up in
nvkm/subdev/mmu/vmmgf100.c. The code is somewhat fancy to generically
deal with different page sizes/etc, but you can mostly ignore that.
Different generations allow different things, which is what you'll
find in the subsequent vmm* files. Pascal gains 48-bit virtual
addresses (up from 40), which I think changes some details around as
well.

Ben - please correct me if I'm wrong. I suspect I missed some details
relative to *actually* making this work, but this should be the gist
of it.

Hope this helps,

  -ilia

On Wed, Sep 29, 2021 at 4:17 PM Joshua Bakita <jbakita@cs.unc.edu> wrote:
>
> Hello,
>
> I'm trying to understand how VRAM PAs are mapped to BAR1 offsets on
> Fermi+, but I'm having difficulty digging through the abstractions in
> nouveau. I spent the better part of yesterday digging through the
> nv50_instobj_*() functions, but I lost track of which page tables are
> being modified and where they're coming from somewhere around level 7
> of indirection/aliasing from the nvkm_kmap() call (aka
> nv50_instobj_acquire()) to the actual nvkm_vmm_iter() logic which I
> think does the mapping.
>
> If page tables are used to map BAR1 offsets to VRAM PAs on Fermi+, I'd
> like to understand their relation to the normal GPU VA to PA page
> tables, and how we tell the hardware which page tables to use for the
> BAR1 mappings.
>
> Best regards,
>
> Joshua Bakita
> PhD Student
> UNC Chapel Hill | Real-Time Systems Group
>
> (Apologies if anyone already received this email, I tried sending it
> earlier and I think it got stuck in moderation.)

  reply	other threads:[~2021-10-01  3:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-29 20:16 [Nouveau] Understanding BAR1 Offset to imem/VRAM PA Mapping Joshua Bakita
2021-10-01  3:45 ` Ilia Mirkin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-09-29 15:09 Joshua Bakita

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='CAKb7UvhUQrbD8tpn=K3KBg4BycFh5zvKM+G0He4onu3dXnYdYw@mail.gmail.com' \
    --to=imirkin@alum.mit.edu \
    --cc=jbakita@cs.unc.edu \
    --cc=nouveau@lists.freedesktop.org \
    /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.