Existing qpi.c makes too many assumptions about the uncore configuration buses location and about slots occupied. Also it restricts itself only to Nehalem CPUs. It should be useful on all Core-based Xeons. On the 2600 v2 (Ivy) machine I have access to, the buses have numbers 31 (BSP socket) and 63 (second socket), and there is no functions pci0.31.0.0 or pci0.63. According to EDS, all devices on the uncore bus occupy slot >= 8.

Scan all buses, not stopping on the first failed match. Scan all slots for function 0 on the found bus, for instance on Ivy there the slot 0 is not decoded at all. Since the scan is quite unsafe, and access to the buses is mostly useful for developers, enable the csr buses scan with the tunable.

Practically, the attach to config buses is required for the intel-pcm pcm-memory.x tool to work, for instance.

I wonder whether qpi attach should have lower priority to ensure that other bus drivers already attached, so that we do not force some innocent normal PCI bus under qpi.

On two-socket Ivy with devinfo I see two pci buses under qpi0, as expected. Also, pciconf -lvc shows the devices which I want to access, for instance

none101@pci0:31:19:4:	class=0x088000 card=0x18a8103c chip=0x0e818086 rev=0x04 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Xeon E7 v2/Xeon E5 v2/Core i7 QPI Ring Registers'
    class      = base peripheral
none102@pci0:31:19:5:	class=0x110100 card=0x18a8103c chip=0x0e368086 rev=0x04 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Xeon E7 v2/Xeon E5 v2/Core i7 QPI Ring Performance Ring Monitoring'
    class      = dasp
    subclass   = performance counters
none103@pci0:31:22:0:	class=0x088000 card=0x18a8103c chip=0x0ec88086 rev=0x04 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Xeon E7 v2/Xeon E5 v2/Core i7 System Address Decoder'
    class      = base peripheral

The pcm-memory.x works on the patched kernel while it refuses to start on unpatched one.