PCI bus_manager does no memory resource assignment

[marcusoverhagen]

The PCI bus_manager does no memory resource assignment

[waddlesplash]

Still an issue?

[euan]

A more detailed explanation of why the PCI bus manager needs resource assignment and what it is might help inspire or motivate someone to take up the task.

[anevilyak]

I may be mistaken, but I believe it's mainly for the case of systems where the BIOS only takes care of assigning resources for the bare minimum devices needed to boot, and leaves the rest to the OS (I.e. the "PnP OS" setting one sometimes sees). In such a case, the bus manager needs to take care of resource configuration for the remaining devices in order for them to be usable.

[euan]

Sounds familiar. Is it still valid? was this for non acpi compliant systems?

[X512]

Memory assignment is implemented for riscv64 PCI ECAM: ​https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/bus_managers/pci/arch/riscv64/arch_pci_controller.cpp#n205. This should be moved or reimplemented in generic PCI bus manager code.

[pulkomandy]

Sounds familiar. Is it still valid? was this for non acpi compliant systems?

Yes, it's still valid.

During boot, the BIOS may or may not assign addresses to each device. You can expect that basic devices (graphics, network, etc) will be initialized because the BIOS needs them. Maybe they will assign addresses to everything, but maybe not.

In the case where the BIOS didn't do it, we see that the BAR registers for the affected device will still be 0 (this is visible in syslog when we dump the PCI information). In this case it is up to us to figure out an address for the device. The basic process is:

• Write FFFFFFFF to the BAR register
• Read back the register to know how much space the device needs, and if it has constraints (memory or IO space, 32 or 64bit addressing, prefetchable or not).
• Restore the initial value of the BAR register

We already do these steps in PCI::_GetBarInfo in the PCI bus manager.

After this step we are left with two types of devices:

• Those which are already mapped by the BIOS, will have an address in their BAR registers already. Now we also know their size.
• Those which are not already mapped, will have an address of 0. We need to allocate them an address and write it to the BAR register.

Now we need to figure out how to allocate that address. It must be in the memory window of the PCI host controller. In the case of devices that are accessed theough a pci-to-pci bridge, we get that info from the bridge, which specifies which memory space it makes visible. However, in the case of devices attached to the root of the PCI bus, it's not clear how we get the info. Apparently it is platform specific and we know it from how we located the PCI bus in the first place. On x86 we use ACPI for that. I don't see where the info is in the ACPI table we use. If you look at the RISC-V ECAM code you will see that it gets the info from the FDT there.

[pulkomandy]

So, after some research, it seems we need to rework our PCI bus detection and initialization quite a bit.

Currently, we find the PCI configuration space by looking at the MCFG ACPI table. This only gives us the address of the configuration space, where we can access the BAR for the PCI devices on the bus.

But the info we need is in the DSDT table, in ACPI nodes with PNP0A03/PNP0A08 cid/hid. Conveniently, ACPICA already detects these and sets the ACPI_PCI_ROOT_BRIDGE flag for us.

We are supposed to find that first, and get the segment and bus numbers from there (_BBN and _SEG methods). From these, we can lookup the corresponding base address in the MCFG. But in addition, we also get the _CRS method, which gives us information about the address range allocated to this PCI bus. Once we know that, we can see which parts of this space are already allocated to devices, and finally use the remaining space to assign addresses to the devices that don't yet have one.

This is how it's done in freeBSD: ​https://www.leidinger.net/FreeBSD/dox/dev_pci/html/d2/d72/pci__host__generic__acpi_8c_source.html#l00117

[X512]

If rework is planned, it will be nice to implement dynamic install and uninstall of PCI host controllers instead of assuming that all controllers are discovered at initialization.

[nephele]

This prevents the touchpad on my laptop from working.

I'd like to work on this.

pulkomandy: the link you posted above looks to be dead to me?

[pulkomandy]

Here's the same file in another place that hosts FreeBSD sources (a more official one):

​https://cgit.freebsd.org/src/tree/sys/dev/pci/pci_host_generic_acpi.c