> You should never access the configuration space directly. Configuration space uses an indexed register approach, and because you don’t own that resource, you and the operating system might get into a race condition over the index.
A driver can access its own device’s configuration space using IRP_MN_READ_CONFIG and IRP_MN_WRITE_CONFIG. There are samples on the web. You shouldn’t be accessing the configuration space of devices you don’t own.
Thanks a lot for clarifying. I now fully understand why to use IRP_MN_READ_CONFIG & IRP_MN_WRITE_CONFIG. I didn’t understand your point of “you and the operating system might get into a race condition over the index”. I am unable to get how race condition can happen if and only if driver read configuration space only.
Let me clarify what I mean
-
Assuming PCIe configuration space (MMIO) is at 0xE000_0000 (obtained from ACPI MCFG table).
-
If I am doing something like
DWORD dwRegisterVal = (DWORD)(*MMIOBaseAddress) // MMIOBaseAddress = 0xE000_0000.
How above code can lead to race condition? And above code will read VendorID and DeviceID for Bus:Device:Function of 0:0:0.
I am not proving you wrong here but I am trying to understand race condition part. Am I missing something here?
******************
Point 2
********************
> o Does Halxxx function(s) use ACPI internally? As an example, windows kernel Hal function “HalTranslateBusAddress(…)” - would that be using ACPI or PCIe config address space to figure out translated address?
That depends on your definition. The PCI bus driver acquire all of this information at boot time and caches it in memory and in the registry. The HAL functions use the tables in memory to return this information. The ACPI DSDT information does not change after boot, so there’s no need to go diving back for that information. That’s a good thing, because ACPI requests are slow.
Yesterday I was reading an article on how different buses are assigned bus addresses starting from Root Complex. And there it mentioned that Hot Plugging devices poses an issue because bus address range might change as resource requirements could not fit for a given bus and it has to be re-adjusted for that device to work. As a result, Bus Tree starting from Root Complex has to be re-configured/re-adjusted.
What you said is that “The PCI bus driver acquire all of this information at boot time and caches it in memory and in the registry”. Does that mean cache is invalidated when address window is re-adjusted for PCI-PCI/PCI-ISA bridges?
o One more question: Why information is stored in registry? Wouldn’t cache be enough as drivers will be using Halxxx functions which effectively will be use cache instead of Registry.