Hi,
I’m trying to enumerate PCI devices in Windows as well as accessing their PCI configuration space. I’m currently coding a user mode application + kernel mode device driver to do that. However, I stuck at how to obtain the PDO of the PCI devices attached in Windows XP/2003? I’m not currently developing a driver for specific PCI device. Therefore, I think using IRP_MN_START_DEVICE is out of question here.
I’ve built PCI device driver that accesses the CF8h-CFCh PCI I/O port directly to do this task as experimental aid. But, I think it’s not the right way implementing a driver that scans the PCI address space.
Can anyone point out the detailed solution to this problem?
TIA,
Darmawan
Accessing cf8 directly is a recipe for disaster, you should never ever
do that. You have no way of coordinating access to this register with
its true owner (PCI.sys). You can enumerate PCI devices in user mode
without the help of a driver, although you cannot access them directly
(unless the function driver exposes such an interface). What is it in
config space that you want the driver/application to receive? If we
know that, you may be able to do everything you want in user mode.
There is no way for a driver to walk the device tree and access another
device’s resources or configuration, imagine the coordination and
testing issues if such a facility existed.
D
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Friday, May 18, 2007 6:13 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Accessing the configuration space of attached PCI
devices
Hi,
I’m trying to enumerate PCI devices in Windows as well as accessing
their PCI configuration space. I’m currently coding a user mode
application + kernel mode device driver to do that. However, I stuck at
how to obtain the PDO of the PCI devices attached in Windows XP/2003?
I’m not currently developing a driver for specific PCI device.
Therefore, I think using IRP_MN_START_DEVICE is out of question here.
I’ve built PCI device driver that accesses the CF8h-CFCh PCI I/O port
directly to do this task as experimental aid. But, I think it’s not the
right way implementing a driver that scans the PCI address space.
Can anyone point out the detailed solution to this problem?
TIA,
Darmawan
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
PCI is a client like anybody else, and ACPI is agent. The true owner is
HAL since the very beginning all the way up to my latest lh weekly
build. And host system does not always (in fact, seldom on newer
platforms) cfc/cf8.
Calvin Guan
Broadcom Corporation
Connecting Everything(r)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-287324-
xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Saturday, May 19, 2007 2:51 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Accessing the configuration space of attached PCI
devices
Accessing cf8 directly is a recipe for disaster, you should never ever
do that. You have no way of coordinating access to this register with
its true owner (PCI.sys). You can enumerate PCI devices in user mode
without the help of a driver, although you cannot access them directly
(unless the function driver exposes such an interface). What is it in
config space that you want the driver/application to receive? If we
know that, you may be able to do everything you want in user mode.
There is no way for a driver to walk the device tree and access
another
device’s resources or configuration, imagine the coordination and
testing issues if such a facility existed.
D
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Friday, May 18, 2007 6:13 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Accessing the configuration space of attached PCI
devices
Hi,
I’m trying to enumerate PCI devices in Windows as well as accessing
their PCI configuration space. I’m currently coding a user mode
application + kernel mode device driver to do that. However, I stuck
at
how to obtain the PDO of the PCI devices attached in Windows XP/2003?
I’m not currently developing a driver for specific PCI device.
Therefore, I think using IRP_MN_START_DEVICE is out of question here.
I’ve built PCI device driver that accesses the CF8h-CFCh PCI I/O
port
directly to do this task as experimental aid. But, I think it’s not
the
right way implementing a driver that scans the PCI address space.
Can anyone point out the detailed solution to this problem?
TIA,
Darmawan
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
The only way to do that (access config space) using defined interfaces is to implement a pci bus filter driver. As bus filter drivers are not supported or documented, you are still left with a bit of an out on a limb problem, however you will not be wrecking platforms in real time by running config space transactions on your own.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-287196-
xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, May 18, 2007 9:13 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Accessing the configuration space of attached PCI
devices
Hi,
I’m trying to enumerate PCI devices in Windows as well as accessing
their PCI configuration space. I’m currently coding a user mode
application + kernel mode device driver to do that. However, I stuck at
how to obtain the PDO of the PCI devices attached in Windows XP/2003?
I’m not currently developing a driver for specific PCI device.
Therefore, I think using IRP_MN_START_DEVICE is out of question here.
I’ve built PCI device driver that accesses the CF8h-CFCh PCI I/O port
directly to do this task as experimental aid. But, I think it’s not the
right way implementing a driver that scans the PCI address space.
Can anyone point out the detailed solution to this problem?
TIA,
Darmawan
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I’m going to borrow the OP’s thread real quick 
In the past, I have had reason access another device’s config space.
Here’s the scenario: Say you have a card that contains several PCI devices
and a PCI bridge. The PCI bridge has a flash, or I2C interface, or whatever
that you need to tweak.
The bridge is part of my hardware, but pci.sys doesn’t see it that way since
it ID’s as a bridge device. Now this happened back in the NT4.0 days, so
maybe things are different now–or maybe I just missed something
altogether…
Anyway, the solution was to play fast-and-loose with cf8. Maybe not a
*good* solution, but it did work for us. I would have loved to be able to
call into pci.sys and do what needed to be done–or load my own driver for
the bridge yet be able to punt enumeration and secondary bus configuration
back to pci.sys.
Shawn
On 5/19/07, Doron Holan wrote:
>
> Accessing cf8 directly is a recipe for disaster, you should never ever
> do that. You have no way of coordinating access to this register with
> its true owner (PCI.sys). You can enumerate PCI devices in user mode
> without the help of a driver, although you cannot access them directly
> (unless the function driver exposes such an interface). What is it in
> config space that you want the driver/application to receive? If we
> know that, you may be able to do everything you want in user mode.
>
> There is no way for a driver to walk the device tree and access another
> device’s resources or configuration, imagine the coordination and
> testing issues if such a facility existed.
>
> D
>
>
Define working for you. I encountered one of these with a customer, and
spent weeks tracking it down to a 3rd party driver. I recomended they sue
the firm that produced the crap. I did make sure that several an OEM I
knew who was considering buying it knew it was crap.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Shawn Brooks” wrote in message news:xxxxx@ntdev…
> I’m going to borrow the OP’s thread real quick
>
> In the past, I have had reason access another device’s config space.
>
> Here’s the scenario: Say you have a card that contains several PCI
> devices
> and a PCI bridge. The PCI bridge has a flash, or I2C interface, or
> whatever
> that you need to tweak.
>
> The bridge is part of my hardware, but pci.sys doesn’t see it that way
> since
> it ID’s as a bridge device. Now this happened back in the NT4.0 days, so
> maybe things are different now–or maybe I just missed something
> altogether…
>
> Anyway, the solution was to play fast-and-loose with cf8. Maybe not a
> good solution, but it did work for us. I would have loved to be able
> to
> call into pci.sys and do what needed to be done–or load my own driver
> for
> the bridge yet be able to punt enumeration and secondary bus
> configuration
> back to pci.sys.
>
> Shawn
>
>
> On 5/19/07, Doron Holan wrote:
>>
>> Accessing cf8 directly is a recipe for disaster, you should never ever
>> do that. You have no way of coordinating access to this register with
>> its true owner (PCI.sys). You can enumerate PCI devices in user mode
>> without the help of a driver, although you cannot access them directly
>> (unless the function driver exposes such an interface). What is it in
>> config space that you want the driver/application to receive? If we
>> know that, you may be able to do everything you want in user mode.
>>
>> There is no way for a driver to walk the device tree and access another
>> device’s resources or configuration, imagine the coordination and
>> testing issues if such a facility existed.
>>
>> D
>>
>>
>
> PCI is a client like anybody else, and ACPI is agent. The true owner is
HAL since the very beginning all the way up to my latest lh weekly build.
Actually, in this context I would use the term “owner” for someone who has an exclusive access to the spinlock that has to be obtained before you can play around with IO ports. Therefore, in this context the term “owner”, apparently, refers to PCI.SYS…
Anton Bassov
Using the cf8 method enabled my company to ship a successful product on
time.
This was an internal (production-line) driver, so I seriously doubt it was
my driver that bit you.
Sue? LOL. Never thought of that–I usually just kick some imaginary
ass then move on to the next problem for more of the same.
Anyway, I don’t want to hijack the OP’s thread–I’ve just always been
curious about this issue.
Shawn
On 5/19/07, Don Burn wrote:
>
> Define working for you. I encountered one of these with a customer, and
> spent weeks tracking it down to a 3rd party driver. I recomended they sue
> the firm that produced the crap. I did make sure that several an OEM I
> knew who was considering buying it knew it was crap.
You are taking me a bit too literally. Nobody is allowed to arbitrarily
touch cf8 directly (or whatever the register base is for pci config
space access), you must only use the approved APIs (which happen to be
exposed by PCI, so from an interface POV, PCI owns the register even if
it uses some other OS component underneath the covers)
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Calvin (Hao)
Guan
Sent: Saturday, May 19, 2007 3:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Accessing the configuration space of attached PCI
devices
PCI is a client like anybody else, and ACPI is agent. The true owner is
HAL since the very beginning all the way up to my latest lh weekly
build. And host system does not always (in fact, seldom on newer
platforms) cfc/cf8.
Calvin Guan
Broadcom Corporation
Connecting Everything(r)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-287324-
xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Saturday, May 19, 2007 2:51 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Accessing the configuration space of attached PCI
devices
Accessing cf8 directly is a recipe for disaster, you should never ever
do that. You have no way of coordinating access to this register with
its true owner (PCI.sys). You can enumerate PCI devices in user mode
without the help of a driver, although you cannot access them directly
(unless the function driver exposes such an interface). What is it in
config space that you want the driver/application to receive? If we
know that, you may be able to do everything you want in user mode.
There is no way for a driver to walk the device tree and access
another
device’s resources or configuration, imagine the coordination and
testing issues if such a facility existed.
D
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Friday, May 18, 2007 6:13 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Accessing the configuration space of attached PCI
devices
Hi,
I’m trying to enumerate PCI devices in Windows as well as accessing
their PCI configuration space. I’m currently coding a user mode
application + kernel mode device driver to do that. However, I stuck
at
how to obtain the PDO of the PCI devices attached in Windows XP/2003?
I’m not currently developing a driver for specific PCI device.
Therefore, I think using IRP_MN_START_DEVICE is out of question here.
I’ve built PCI device driver that accesses the CF8h-CFCh PCI I/O
port
directly to do this task as experimental aid. But, I think it’s not
the
right way implementing a driver that scans the PCI address space.
Can anyone point out the detailed solution to this problem?
TIA,
Darmawan
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
From a public API point of view, yes, the owner is pci.sys. That’s an
arbitrary boundary condition imposed by the os vendor for good reasons.
I have no problem with that.
But from the architectural point of view, I am not sure if it’s still
true. I’m not a CS graduate; I probably could never get that right.
An obvious example I’ve seen is that ACPI can power down my PDO by
config cycles without invoking any part of PCI.sys. Going one step
further, I found that ACPI.sys is merely a subscriber of some kind of
service that HAL has offered.
Calvin Guan
Broadcom Corporation
Connecting Everything(r)
P.S. I have no interest in deliberately using any unapproved means in
production environment even though I happen to know a lot of them as a
co-product of debugging my @#$%ing systems over the years-
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-287335-
xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Saturday, May 19, 2007 5:33 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Accessing the configuration space of attached PCI
devices
You are taking me a bit too literally. Nobody is allowed to
arbitrarily
touch cf8 directly (or whatever the register base is for pci config
space access), you must only use the approved APIs (which happen to be
exposed by PCI, so from an interface POV, PCI owns the register even
if
it uses some other OS component underneath the covers)
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Calvin (Hao)
Guan
Sent: Saturday, May 19, 2007 3:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Accessing the configuration space of attached PCI
devices
PCI is a client like anybody else, and ACPI is agent. The true owner
is
HAL since the very beginning all the way up to my latest lh weekly
build. And host system does not always (in fact, seldom on newer
platforms) cfc/cf8.
Calvin Guan
Broadcom Corporation
Connecting Everything(r)
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-287324-
> xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Saturday, May 19, 2007 2:51 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Accessing the configuration space of attached
PCI
> devices
>
> Accessing cf8 directly is a recipe for disaster, you should never
ever
> do that. You have no way of coordinating access to this register
with
> its true owner (PCI.sys). You can enumerate PCI devices in user
mode
> without the help of a driver, although you cannot access them
directly
> (unless the function driver exposes such an interface). What is it
in
> config space that you want the driver/application to receive? If we
> know that, you may be able to do everything you want in user mode.
>
> There is no way for a driver to walk the device tree and access
another
> device’s resources or configuration, imagine the coordination and
> testing issues if such a facility existed.
>
> D
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@gmail.com
> Sent: Friday, May 18, 2007 6:13 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Accessing the configuration space of attached PCI
> devices
>
> Hi,
> I’m trying to enumerate PCI devices in Windows as well as
accessing
> their PCI configuration space. I’m currently coding a user mode
> application + kernel mode device driver to do that. However, I stuck
at
> how to obtain the PDO of the PCI devices attached in Windows
XP/2003?
> I’m not currently developing a driver for specific PCI device.
> Therefore, I think using IRP_MN_START_DEVICE is out of question
here.
> I’ve built PCI device driver that accesses the CF8h-CFCh PCI I/O
port
> directly to do this task as experimental aid. But, I think it’s not
the
> right way implementing a driver that scans the PCI address space.
> Can anyone point out the detailed solution to this problem?
>
> TIA,
> Darmawan
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>But from the architectural point of view, I am not sure if it’s still
true. I’m not a CS graduate; I probably could never get that right.
Jake Oshins told once here that 0xcf8/0xcfc are obsolete (though still
supported) and are replaced by ACPI methods.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Hi all, thanks for the suggestions. Anyway, what I need are finding values of the PCI device IDs, Vendor IDs, BARs and XROMBARs of the PCI devices attached to the BUS.
As has been mentioned above, access to the configuration space of a device is restricted to the drivers on the stack for that device. So to get arbitrary access to arbitrary device config space, you have to write a bus filter, which isn’t documented.
So really, what you are supposed to do is get information about devices from the user-mode SetupDi and CM_ functions. Device IDs and vendor IDs are encoded in hardware IDs, which are accessible. BARs are encoded in resources. ROMBARs are in the resources in the very rare case that they are enabled. It is possible to get the hierarchy of PCI devices, and to get basically all the information available in device manager.
Plus, in Vista we have added custom device properties for PCI devices to expose things like bus type (PCIe vs PCI-X), speed, and other hardware capabilities. So the information available from usermode is really pretty rich.
Dave
Another reply, this time to Shawn Brooks.
The reason the rules are set up to allow config access only to drivers on the stack is that each PCI device is managed and moved through PnP/Power state transitions independently. If your driver, on the side, is accessing config space while a user in device manager decides to disable the bridge that is part of your device (or if something similar is done programmatically by some tool, or something else happens), then either your config access won’t work right, or your device will not work right because it relies on the bridge being active. In either case there is no coordination and the result can’t be good. This is why the rule only allowing config space access to the stack has been backed up by rules dictating that each PCI function needs to be completely independent. In a world that allows for things to be very dynamic, this kind of hardware design is a real problem.
And just to reiterate, using CFC/CF8 is no solution at all. it is like playing russian roulette with the system. Spin the barrel, and hope that no other thread is making a config access at the same time. Here’s an example. Imagine if you did this around the same time another driver tried to mask an interrupt in preparation for disconnecting. If this driver wrote to CF8, and then you slammed in and wrote to CF8 and CFC, and then the other thread wrote CFC, your device would get an interrupt mask value written to it and the other device would get nothing. It would then interrupt storm as soon as it disconnected its interrupt, bringing down the system.
This is not to mention the fact that CFC/CF8 isn’t portable (doesn’t work this way on IA64), and on x86/x64 doesn’t support the full range of config space available on newer devices, nor the full number of devices available on newer systems.
Anyway, Shawn hopefully this provides the background you were looking for. Hopefully it also steers anyone else thinking of going that direction away from CFC/CF8.
Dave
I’m not sure how your answer is related to the quote to my text.
I know exactly how config cycles are committed whether using cfc or
other newer mechanism, from both sw, drvier, BIOS, PCI system protocols,
and VHDL implementation.
Calvin Guan
Broadcom Corporation
Connecting Everything(r)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-287370-
xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Sunday, May 20, 2007 2:09 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Accessing the configuration space of attached PCI
devices
>But from the architectural point of view, I am not sure if it’s still
>true. I’m not a CS graduate; I probably could never get that right.
Jake Oshins told once here that 0xcf8/0xcfc are obsolete (though still
supported) and are replaced by ACPI methods.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Dave,
Yes, I understand why it’s a bad idea. I was really looking for a comment
on the right way to do the things I mentioned. To restate the problem, the
PCI bus driver claims all PCI bridge devices as it’s own. This simply isn’t
always valid. Adapters can have bridge chips that require configuration
outside of what the PCI bus driver provides. That is, the bridge chips in
question are more than just bridge chips. They provide adapter specific
functionality–usually in the form of extended config space registers used
to control I/O ports, SPI flash, etc.
The solution I would have liked to have seen is an entry point into the PCI
bus driver that allowed synchronized access to PCI config space. That or
the ability to load up a bus filter driver.
I know that there are applications that do all sorts of things with PCI
configuration space–reading, writing, etc. I’ve always wondered what they
did to avoid synchronization problems with the PCI bus driver and function
drivers.
Shawn
On 5/20/07, xxxxx@microsoft.com wrote:
>
> Another reply, this time to Shawn Brooks.
>
> The reason the rules are set up to allow config access only to drivers on
> the stack is that each PCI device is managed and moved through PnP/Power
> state transitions independently. If your driver, on the side, is accessing
> config space while a user in device manager decides to disable the bridge
> that is part of your device (or if something similar is done
> programmatically by some tool, or something else happens), then either your
> config access won’t work right, or your device will not work right because
> it relies on the bridge being active. In either case there is no
> coordination and the result can’t be good. This is why the rule only
> allowing config space access to the stack has been backed up by rules
> dictating that each PCI function needs to be completely independent. In a
> world that allows for things to be very dynamic, this kind of hardware
> design is a real problem.
>
> And just to reiterate, using CFC/CF8 is no solution at all. it is like
> playing russian roulette with the system. Spin the barrel, and hope that no
> other thread is making a config access at the same time. Here’s an
> example. Imagine if you did this around the same time another driver tried
> to mask an interrupt in preparation for disconnecting. If this driver wrote
> to CF8, and then you slammed in and wrote to CF8 and CFC, and then the other
> thread wrote CFC, your device would get an interrupt mask value written to
> it and the other device would get nothing. It would then interrupt storm as
> soon as it disconnected its interrupt, bringing down the system.
>
> This is not to mention the fact that CFC/CF8 isn’t portable (doesn’t work
> this way on IA64), and on x86/x64 doesn’t support the full range of config
> space available on newer devices, nor the full number of devices available
> on newer systems.
>
> Anyway, Shawn hopefully this provides the background you were looking
> for. Hopefully it also steers anyone else thinking of going that direction
> away from CFC/CF8.
>
> Dave
>
>
Shawn,
Understood. I’ve seen these designs in the past, so I know what you’re talking about. In your case the right thing to do would be to load as a filter driver on your bridge chip. You wouldn’t be able to guarantee a lot about the ordering between the bridge chip and the other chips involved, but at least with a driver on the stack you would know what was going on. And with a driver on the stack you’d be able to do the config accesses.
That’s really the upshot here - if you want to do config access you really need to have a driver on the stack because PnP/Power state transitions get sent to the driver stack but aren’t visible outside that driver stack. Since this bridge is really part of your device, loading a filter on it isn’t unreasonable. Would it be nice if we did some work to allow multiple functions to be associated together and one driver loaded to control them all? Perhaps, but that would have opened up another can of worms (how does PCI.SYS get involved to do standard bridge enumeration?) so we chose to advise against this kind of design. Over the years more designs like this have moved to being non-transparent bridges that hide all of the different logic from standard enumeration, and that load one driver to handle it all. This kind of design is much more PnP friendly.
The OP wanted more carte blanche access to config space. This kind of thing wouldn’t work for him.
Dave
Dave,
Ah, I see. Of course.
Thanks for the explanation!
Shawn
On 5/20/07, xxxxx@microsoft.com wrote:
>
> Shawn,
>
> Understood. I’ve seen these designs in the past, so I know what you’re
> talking about. In your case the right thing to do would be to load as a
> filter driver on your bridge chip. You wouldn’t be able to guarantee a lot
> about the ordering between the bridge chip and the other chips involved, but
> at least with a driver on the stack you would know what was going on. And
> with a driver on the stack you’d be able to do the config accesses.
>
> That’s really the upshot here - if you want to do config access you really
> need to have a driver on the stack because PnP/Power state transitions get
> sent to the driver stack but aren’t visible outside that driver
> stack. Since this bridge is really part of your device, loading a filter on
> it isn’t unreasonable. Would it be nice if we did some work to allow
> multiple functions to be associated together and one driver loaded to
> control them all? Perhaps, but that would have opened up another can of
> worms (how does PCI.SYS get involved to do standard bridge enumeration?)
> so we chose to advise against this kind of design. Over the years more
> designs like this have moved to being non-transparent bridges that hide all
> of the different logic from standard enumeration, and that load one driver
> to handle it all. This kind of design is much more PnP friendly.
>
> The OP wanted more carte blanche access to config space. This kind of
> thing wouldn’t work for him.
>
> Dave
>
xxxxx@microsoft.com wrote:
As has been mentioned above, access to the configuration space of a device is restricted to the drivers on the stack for that device. So to get arbitrary access to arbitrary device config space, you have to write a bus filter, which isn’t documented.
Anyway, this is only a side note. Why Microsoft doesn’t document the bus driver?
So really, what you are supposed to do is get information about devices from the user-mode SetupDi and CM_ functions. Device IDs and vendor IDs are encoded in hardware IDs, which are accessible. BARs are encoded in resources. ROMBARs are in the resources in the very rare case that they are enabled. It is possible to get the hierarchy of PCI devices, and to get basically all the information available in device manager.
Can you please elaborate more on about the resources? what resources do you mean? Address space usage in Windows? How can obtain it (what is the API)?
Or all of the function/API needed are in the API to the device manager? Suggestion on keyword to look for the function in MSDN? Sorry, I’ve never used this kind of API before. That’s why I’m clueless at this point.
Plus, in Vista we have added custom device properties for PCI devices to expose things like bus type (PCIe vs PCI-X), speed, and other hardware capabilities. So the information available from usermode is really pretty rich.
Is it documented in WDK?
TIA,
Darmawan
Bus drivers are documented, bus filter drivers are not. A bus driver
enumerates child stacks. A bus filter driver sits on top of a bus
driver and dynamically starts attaching to and filtering the children
that the bus driver enumerates (w/out the help of an INF or other
installation mechanism).
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Darmawan Salihun
Sent: Monday, May 21, 2007 6:09 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Accessing the configuration space of attached PCI
devices
xxxxx@microsoft.com wrote:
As has been mentioned above, access to the configuration space of a
device is restricted to the drivers on the stack for that device. So to
get arbitrary access to arbitrary device config space, you have to write
a bus filter, which isn’t documented.
Anyway, this is only a side note. Why Microsoft doesn’t document the bus
driver?
So really, what you are supposed to do is get information about
devices from the user-mode SetupDi and CM_ functions. Device IDs and
vendor IDs are encoded in hardware IDs, which are accessible. BARs are
encoded in resources. ROMBARs are in the resources in the very rare
case that they are enabled. It is possible to get the hierarchy of PCI
devices, and to get basically all the information available in device
manager.
Can you please elaborate more on about the resources? what resources do
you mean? Address space usage in Windows? How can obtain it (what is the
API)?
Or all of the function/API needed are in the API to the device manager?
Suggestion on keyword to look for the function in MSDN? Sorry, I’ve
never used this kind of API before. That’s why I’m clueless at this
point.
Plus, in Vista we have added custom device properties for PCI devices
to expose things like bus type (PCIe vs PCI-X), speed, and other
hardware capabilities. So the information available from usermode is
really pretty rich.
Is it documented in WDK?
TIA,
Darmawan
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer