Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Muni Sekhar <munisekharrms@gmail.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: Query Regarding PCI Configuration Space Mapping and BAR Programming
Date: Wed, 19 Mar 2025 14:15:42 -0500	[thread overview]
Message-ID: <20250319191542.GA1053142@bhelgaas> (raw)
In-Reply-To: <CAHhAz+ibkpwJ4vduDGC+n7Pjp=4ZbtkVmvQFoFXgZYV+TcDWXQ@mail.gmail.com>

On Wed, Mar 19, 2025 at 11:27:07PM +0530, Muni Sekhar wrote:
> Dear Linux-PCI Maintainers,
> 
> I have a few questions regarding PCI configuration space and Base
> Address Register (BAR) programming:
> 
> PCI Configuration Space Mapping:
> PCI devices have standard registers (Device ID, Vendor ID, Status,
> Command, etc.) in their configuration space.
> These registers are mapped to memory locations. 

In general, config registers are not mapped to memory locations.

Some systems use the ECAM mechanism for config access, which is
basically memory-mapped I/O that converts CPU memory accesses to PCI
config accesses.  This mechanism is hidden inside the Linux config
accessors (pci_read_config_word(), etc), and drivers should not use
ECAM directly.

> How can we determine
> the exact memory location where these configuration space registers
> are mapped?

Drivers use pci_read_config_word() and similar interfaces to access
config registers.  Userspace can use the setpci utility.

> Base Address Registers (BARs) Programming:
> How are BAR registers programmed, and what ensures they do not
> conflict with other devices mapped memory in the system?
> If a BAR mapping clashes with another device’s memory range, how does
> the system handle this?
> 
> Does the BIOS/firmware allocate BAR addresses, or does the OS have a
> role in reconfiguring them during device initialization?

On x86 systems, the BIOS generally assigns BAR addresses.  Linux
doesn't change these unless they are invalid.  Some firmware does not
assign BARs, and generally firmware does not assign BARs for hot-added
devices.  In those cases, Linux assigns them.

If Linux notices a conflict, it tries to reassign BARs to avoid the
conflict.

> If you could provide any source code references from the Linux kernel
> that handle these aspects, it would be greatly appreciated.

Here's the function that reads BARs when Linux enumerates a device:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/probe.c?id=v6.13#n176

  reply	other threads:[~2025-03-19 19:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-19 17:57 Query Regarding PCI Configuration Space Mapping and BAR Programming Muni Sekhar
2025-03-19 19:15 ` Bjorn Helgaas [this message]
2025-03-20  1:49   ` Hans Zhang
2025-03-21 11:08   ` Muni Sekhar
2025-03-21 17:30     ` Bjorn Helgaas

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=20250319191542.GA1053142@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=munisekharrms@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox