Is PCI "CF8h/CFCh" IO port addresses only applicable to processors with an IO address space?

Question

Some CPU like x86 processor has two address spaces. One for memory and one for IO. And different instructions to access them.

And the PCI 3.0 spec also mentions some important IO addresses:

Two DWORD I/O locations are used to generate configuration transactions for PC-AT compatible systems. The first DWORD location (CF8h) references a read/write register that is named CONFIG_ADDRESS. The second DWORD address (CFCh) references a read/write register named CONFIG_DATA.

So it seems PCI 3.0 spec is tightly coupled to processors that does implement IO address space. And that's the a priori knowledge that SW/FW writers should know.

So what about the other processor archs that don't have IO address space? Like ARM. How can they interact with the PCI configuration space?

ADD 1 --- 9:19 2023/4/19

A related thread:

https://electronics.stackexchange.com/questions/661331/is-pcie-io-address-space-meaningless-for-arm-based-system

Answer 1

The paragraph immediately preceding the one quoted in the question directly addresses the question. It says:

Systems must provide a mechanism that allows software to generate PCI configuration transactions. ... For PC-AT compatible systems, the mechanism for generating configuration transactions is defined and specified in this section. ... For other system architectures, the method of generating configuration transactions is not defined in this specification.

In other words, systems that are not PC-AT compatible must provide a mechanism, but it is specified elsewhere. The PCI spec isn't tightly coupled to PC-AT systems, but it doesn't define the mechanism for other types of systems.

The paragraph in the question only applies to PC-AT compatible systems.

Answer 2

Below quote from here clears things up:

The method for generating configuration cycles is host dependent. In IA machines, special I/O ports are used. On other platforms, the PCI configuration space can be memory-mapped to certain address locations corresponding to the PCI host bridge in the host address domain.

And

I/O space can be accessed differently on different platforms. Processors with special I/O instructions, like the Intel processor family, access the I/O space with in and out instructions. Machines without special I/O instructions will map to the address locations corresponding to the PCI host bridge in the host address domain. When the processor accesses the memory-mapped addresses, an I/O request will be sent to the PCI host bridge, which then translates the addresses into I/O cycles and puts them on the PCI bus.

So for non-IA platform, MMIO can just be used instead. And the platform specs should document that memory-mapped address for the PCI host bridge as the a priori knowledge for SW/FW writers.

ADD 1 - 14:36 2023/2/5

From the digital design's perspective, the host CPU and the PCIe subsystem are just two separate IP blocks. And the communication between them is achieved by a bunch of digital signals in the form of address/data/control lines. As long as the signals can be conveyed, the communication can be made.

For x86 CPUs, the memory address space and IO address space are just different usage of address lines down to the earth. I don't think there's any strong reason that memory addresses cannot be used to communicate with PCIe subsystem. I think it's a more logical choice back then to use I/O addresses for PCIe because PCIe is deemed as I/O.

So the real critical thing I think, is to convey the digital signals in proper format between IPs. PCIe is independent of CPU architectures and cares nothing about what lines to be used. For ARM, there's nothing unnatural to use memory addresses, i.e., MMIO. After all it's digital signals and are capable of passing necessary information properly.