How to access the PCI Config Space from a different device?

Hi,

Is there any way to access the PCI Config Space from a different Bus? The situation is that the device is connected through a PCI Express Upstream Switch Port and I need to access that device (the switch port) to query some info. Is there any way to do it without the need of a filter driver?

On Linux is as easy as just jumping two levels in the file system, but not sure how to get this info on Windows Kernel.

Thank you

I am confused as to why you would want to do this. what bus other than PCIe would you be in? perhaps you want to do this from just a general KM context?

The intent was to access the parent pci bus config space. That actually
could be a legitimate thing to do for some devices on some platforms.

Mark Roddy

Sorry for the late response.

We actually ended up using the obscure function HalGetBusDataByOffset, and it’s working, seems to be read only which is fine and it’s limited only to the 256 bytes of the common PCI Header, doesn’t cover the vendor specific stuff, but that’s fine, it works.

Thanks all.

HalGetBusDataByOffset isn’t obscure… it’s obsolete. It is not likely to work in certain situations, and it’s use is a common reason for blue screens.

@“Peter_Viscarola_(OSR)” said:
HalGetBusDataByOffset isn’t obscure… it’s obsolete. It is not likely to work in certain situations, and it’s use is a common reason for blue screens.

Do you mean like undefined behavior? I am warrantying its access for only PASSIVE_LEVEL, I was testing this, trying to access different buses and devices, the worst it happened was that the function failed. Do you have concrete examples on which scenarios it could lead to bug checks?

The issue is that PCI configuration space is owned by the PCI bus driver, pci.sys. HalGetBusDataByOffset bypasses the PCI bus driver. Some of the configuration space access methods are stateful; you put an address in one register, and read the results from another. If you sneak in the middle, pci.sys’s access gets screwed up.

Do you mean like undefined behavior?

I mean like “unsupported to the point where the docs have been removed, does not work in some cases, and may disappear from the binaries” (though I frankly doubt it’ll ever disappear).

HalGetBusDataByOffset was rendered obsolete 20 years ago when PnP was introduced. After about 20 years, even Windows can sometimes retire an API.

Before PnP, drivers walked up the PCI bus enumerating the VID and DID of the device in each slot, until they found the device(s) they supported. This was done with HalGetBusData. PnP rendered that activity obsolete, as we now have a very different model for resource ownership (as Mr. Roberts alluded to). It is not uncommon for drivers to crash the system attempting to walk the bus with HalGetBusData. When the API was officially broken in Windows 8, we got lots of calls from folks with old drivers that their code was suddenly blue screening systems. So, in many cases, we had the pleasure of rewriting those drivers for them.

You use an API that’s obsolete, no longer documented, and known to cause blue screens at your own risk.

Peter

IIRC this DDI was dangerous to use when it wasn’t obsolete and was the only way to perform certain tasks. That was NT 4 days and my memory might not be right