Editing PCI configuration space (section)

==Software implementation==
Configuration reads and writes can be initiated from the CPU in two ways: one legacy method via I/O addresses {{mono|0xCF8}} and {{mono|0xCFC}}, and another called memory-mapped configuration.<ref>{{cite web |title=Accessing PCI Express* Configuration Registers Using Intel Chipsets |url=http://www.csit-sun.pub.ro/~cpop/Documentatie_SMP/Intel_Microprocessor_Systems/Intel_ProcessorNew/Intel%20White%20Paper/Accessing%20PCI%20Express%20Configuration%20Registers%20Using%20Intel%20Chipsets.pdf |publisher=Intel Corporation |accessdate=27 September 2018}}</ref>

The legacy method was present in the original PCI, and it is called Configuration Access Mechanism (CAM). It allows for 256 bytes of a device's address space to be reached indirectly via two 32-bit registers called PCI CONFIG_ADDRESS and PCI CONFIG_DATA. These registers are at addresses {{mono|0xCF8}} and {{mono|0xCFC}} in the x86 I/O address space.<ref>{{Cite web
 | url = http://wiki.osdev.org/PCI#Configuration_Mechanism_.231
 | title = PCI Configuration Mechanism #1
 | date = 2015-01-01 | accessdate = 2015-01-01
 | website = osdev.org
}}</ref> For example, a software driver (firmware, OS kernel or kernel driver) can use these registers to configure a PCI device by writing the address of the device's register into CONFIG_ADDRESS, and by putting the data that is supposed to be written to the device into CONFIG_DATA. Since this process requires a write to a register in order to write the device's register, it is referred to as "indirection".

The format of CONFIG_ADDRESS is the following:

<syntaxhighlight lang="c">
0x80000000 | bus << 16 | device << 11 | function <<  8 | offset
</syntaxhighlight>

As explained previously, addressing a device via Bus, Device, and Function (BDF) is also referred to as "addressing a device geographically." See <code>arch/x86/pci/early.c</code> in the [[Linux kernel]] code for an example of code that uses geographical addressing.<ref>{{cite web
 | url = https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/x86/pci/early.c?id=refs/tags/v3.12.7
 | title = kernel/git/stable/linux-stable.git: arch/x86/pci/early.c (Linux kernel stable tree, version 3.12.7)
 | accessdate = 2014-01-10
 | publisher = [[kernel.org]]
}}</ref>

When extended configuration space is used on some AMD CPUs, the extra bits 11:8 of the offset are written to bits 27:24 of the CONFIG_ADDRESS register:<ref>{{cite web
 | url = https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/arch/x86/pci/direct.c?id=refs/tags/v3.12.7#n16
 | title = kernel/git/stable/linux-stable.git: arch/x86/pci/direct.c (Linux kernel stable tree, version 3.12.7)
 | accessdate = 2017-09-11
 | publisher = [[kernel.org]]
}}</ref><ref>{{cite web |last1=Richter |first1=Robert |title=x86: add PCI extended config space access for AMD Barcelona |url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=831d991821daedd4839073dbca55514432ef1768 |publisher=kernel.org |accessdate=26 September 2018}}</ref>

<syntaxhighlight lang="c">
0x80000000 | (offset & 0xf00) << 16 | bus << 16 | device << 11 | function <<  8 | (offset & 0xff)
</syntaxhighlight>

The second method was created for PCI Express. It is called Enhanced Configuration Access Mechanism (ECAM). It extends device's configuration space to 4&nbsp;KB, with the bottom 256 bytes overlapping the original (legacy) configuration space in PCI. The section of the addressable space is "stolen" so that the accesses from the CPU don't go to memory but rather reach a given device in the PCI Express fabric. During system initialization, BIOS determines the base address for this "stolen" address region and communicates it to the root complex and to the operating system.

Each device has its own 4&nbsp;KB space and each device's info is accessible through a simple array <code>dev[bus][device][function]</code> so that 256&nbsp;MB of physical contiguous space is "stolen" for this use (256 buses × 32 devices × 8 functions × 4&nbsp;KB = 256&nbsp;MB). The base physical address of this array is not specified. For example, on modern x86 systems the ACPI tables contain the necessary information.<ref>{{cite web
 | url = http://wiki.osdev.org/XSDT
 | title = XSDT - OSDev Wiki
 | accessdate = 2017-04-30
}}</ref>