I’m trying to read from configuration space beyond offset 0x40 in PCI configuration space, and was curious if anyone is familiar with a facility that the WDF provides for doing so.
Any information you might be able to share would be greatly appreciated as always.
-Shane
WDF does nothing for you here other than letting you send a query interface irp (if that is what you need) a bit easier than WDM.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, October 16, 2008 11:24 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Reading from device dependent region in PCI Config space?
I’m trying to read from configuration space beyond offset 0x40 in PCI configuration space, and was curious if anyone is familiar with a facility that the WDF provides for doing so.
Any information you might be able to share would be greatly appreciated as always.
-Shane
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
You aren’t by any chance related to rahumath ali, are you?
http://msdn.microsoft.com/en-us/library/aa906253.aspx?ppud=4
Windows Driver Kit: Buses
Accessing PCI Device Configuration Space
On Thu, Oct 16, 2008 at 2:24 PM, wrote:
> I’m trying to read from configuration space beyond offset 0x40 in PCI
> configuration space, and was curious if anyone is familiar with a facility
> that the WDF provides for doing so.
>
> Any information you might be able to share would be greatly appreciated as
> always.
>
> -Shane
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Mark Roddy
Mark,
Nope. No relation to rahumath. I actually ran that name through google, and felt a little stupid seeing that they were recently causing a headache around here. I lurk around these boards and occasionally ask a question or two just trying to learn as much as possible. I failed to check the last couple pages for any related questions.
The best documentation I have found so far is the Hollis Tech paper, but it’s a little older now and I was curious if there were other preferred methods for getting into config space.
Didn’t mean to throw a topic out there that had been recently drug through the mud. My bad.
-Shane
How can I target the device for which I’d like to read the configuration space from if the driver for that device isn’t mine?
If I had written the device that I am targeting I could have possibly registered my device interface, thus allowing me to get PnP notification of device arrival/removal. Nothing tells me that the device I’m targeting didn’t do this, but how can I get the GUID specifying the appropriate device interface class?
If I had the right GUID, I could register for PnP notification, get a symbolic name, and create a new WdfTarget and open it using the symbolic name. From that I could get the device object using something like WdfIoTargetWdmGetTargetDeviceObject(). Since I’d now have a handle of the device object I could create an IRP and do an IoDriverCall(devObject, irp).
Well, I guess that’s what I was thinking I could do if I had the target device interface GUID. Am I WAY out to lunch here? I’m a rookie at this stuff, so take it easy.
There is no one GUID you can use. It will have to be specific to each device class you want to target.
But once you have a devobj for the remote device, what are you going to do? Send a query interface for bus standard and then read config space? What if the driver for the remote device has turned the device off and it is in d3? What if the remote driver does this in the middle of your read? What if you read a volatile value and the act of reading it destroys the value that the remote driver needs?
…or more succinctly, why do you need to party on a device that is not yours?
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, October 16, 2008 2:47 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Reading from device dependent region in PCI Config space?
How can I target the device for which I’d like to read the configuration space from if the driver for that device isn’t mine?
If I had written the device that I am targeting I could have possibly registered my device interface, thus allowing me to get PnP notification of device arrival/removal. Nothing tells me that the device I’m targeting didn’t do this, but how can I get the GUID specifying the appropriate device interface class?
If I had the right GUID, I could register for PnP notification, get a symbolic name, and create a new WdfTarget and open it using the symbolic name. From that I could get the device object using something like WdfIoTargetWdmGetTargetDeviceObject(). Since I’d now have a handle of the device object I could create an IRP and do an IoDriverCall(devObject, irp).
Well, I guess that’s what I was thinking I could do if I had the target device interface GUID. Am I WAY out to lunch here? I’m a rookie at this stuff, so take it easy.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Doron,
I like your style… The reason I need to party with this device is as follows. The device utilizes the extended configuration space to store off core temperature values. I need a way to periodically poll the device temperature. It’s for a miscellaneous controller for an Opteron processor to be specific.
-Shane
How about having the driver which controls the device expose the information for you?
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, October 16, 2008 3:17 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Reading from device dependent region in PCI Config space?
Doron,
I like your style… The reason I need to party with this device is as follows. The device utilizes the extended configuration space to store off core temperature values. I need a way to periodically poll the device temperature. It’s for a miscellaneous controller for an Opteron processor to be specific.
-Shane
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
That would be rather nice if the device driver exposed that information for me… Unfortunately it appears as though the fine folks at AMD haven’t provided documentation for a means to interact with this host bridge device driver, and as such I have no idea what the driver for this device actually does/doesn’t expose.
Doron,
Do you suggest write that driver or have it driver from device vendor ?
I don’t know what device is Shane talking about but for nvidia mcp55 chip the CPU temperature (according non-official info) can be read from PCI bus 0, device 24, func 3, offset 0xe4.
Device manager has “PCI standard host CPU bridge” there. About the driver DevMan is saying “No driver files are required or have been…”
Igor
xxxxx@gmail.com wrote:
Do you suggest write that driver or have it driver from device vendor ?
I don’t know what device is Shane talking about but for nvidia mcp55 chip the CPU temperature (according non-official info) can be read from PCI bus 0, device 24, func 3, offset 0xe4.
Device manager has “PCI standard host CPU bridge” there. About the driver DevMan is saying “No driver files are required or have been…”
There is no safe way to get this information. You can use
HalGetBusData, as long as you acknowledge that it is dangerous.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Same deal as Igor except different CPU. There isn’t a driver loaded for the device for which the data I need resides.
I have the Hollis Tech document that talks about using the HalGetBusData approach, but my question regarding using this approach is how do I target the device correctly? How can do I get the device object of the device I’m targetting?
Thanks Tim,
That’s what I was afraid to hear ;(
Igor
Don’t warry Shane
I have Opteron 1210 as well.
For the testing I used
HalGetBusDataByOffset( PCIConfiguration, BusN, SLotN, …, offset - 0xe4
I’ve got the numbers from BIOS developers and they promised it’s a constant at least for our m/b
P.S. But hush… I did not say that
Well you could write a driver for it, simply to gain access to the PDO.
Given the PDO you can then get through that to the PCI bus driver and its
access methods for PCI config space.
On Thu, Oct 16, 2008 at 7:13 PM, wrote:
> Same deal as Igor except different CPU. There isn’t a driver loaded for
> the device for which the data I need resides.
>
> I have the Hollis Tech document that talks about using the HalGetBusData
> approach, but my question regarding using this approach is how do I target
> the device correctly? How can do I get the device object of the device I’m
> targetting?
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Mark Roddy
> But once you have a devobj for the remote device, what are you going to do?
Well, the only reasonable thing to do seems to query interface, get function pointers and call functions - you should not access any driver data/resources, including accessing configuration space, on your own, because the target driver is the only one who is able to handle synchronization properly…
What if the driver for the remote device has turned the device off and it is in d3?
What if the remote driver does this in the middle of your read? What if you read a volatile value
and the act of reading it destroys the value that the remote driver needs?
Well, if you invoke driver’s callbacks it is supposed to take care of all these issues, don’t you think…
Therefore, they will arise only if you try to access driver’s resources without its knowledge…
Anton Bassov
>Well, if you invoke driver’s callbacks it is supposed to take care of all these issues, don’t you think…
Therefore, they will arise only if you try to access driver’s resources without its knowledge…
well, if you knew the architecture of how bus interface std worked, you would already know the answer. the bus driver (pci.sys) is the one that provides the callbacks via the PDO, not the FDO who controls the resources. the interface is meant to be used by the FDO driver, not someone outside of the stack. so, by the fact that the pdo is the one providing the callbacks, all of the issues i outlined can still apply
d
From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com [xxxxx@hotmail.com]
Sent: Thursday, October 16, 2008 9:52 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Reading from device dependent region in PCI Config space?
But once you have a devobj for the remote device, what are you going to do?
Well, the only reasonable thing to do seems to query interface, get function pointers and call functions - you should not access any driver data/resources, including accessing configuration space, on your own, because the target driver is the only one who is able to handle synchronization properly…
What if the driver for the remote device has turned the device off and it is in d3?
What if the remote driver does this in the middle of your read? What if you read a volatile value
and the act of reading it destroys the value that the remote driver needs?
Well, if you invoke driver’s callbacks it is supposed to take care of all these issues, don’t you think…
Therefore, they will arise only if you try to access driver’s resources without its knowledge…
Anton Bassov
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> well, if you knew the architecture of how bus interface std worked, you would already know the answer.
I know it - don’t worry about that…
the bus driver (pci.sys) is the one that provides the callbacks via the PDO,
not the FDO who controls the resources. the interface is meant to be used by the FDO driver,
not someone outside of the stack.
Hold on - let’s decide what we are speaking about. I am not saying that one should query PDO itself - instead, you would normally forward the query to the top of the stack. Consider the scenario when there is a filter above FDO, and, for this or that reason, it wants to make use of these callbacks(I know that normally you would expect such filter to be below FDO, but technically there is no reason why upper filter may not want to do it). Therefore, if FDO makes use of a given interface it would be quite unwise for it to pass the results of the query right to the caller for the reasons that you have described in your earlier post - instead, it would rather make sense to encapsulate them in FDOs handlers that would take care of these issues, and forward the request to the bus driver . After all, FDOs and filters may optionally handle IRP_MN_QUERY_INTERFACE, although, unlike bus drivers they are not required to do so…
Therefore, I would say that if the issue that you have described arise, it is FDOs, rather than caller’s, fault…
Anton Bassov
Doron,
Do you mean it can be a filter driver in PCI stack ?
Igor
Again, lack of practical experience here is showing ;). Yes, you send the query to the top of the stack, but for 99% of the stacks out there, only the PDO answers the query interface. So while the FDO could aggregate the interface that the PDO provides into its own interface, this is barely ever, if never, done. Furthermore, there is the power issue related to IRQL and a direct function call. Even if the FDO did aggregate, GetBusData can be called at IRQL > passive and if the device is currently off, there is no way to synchronously power it up by the time the function returns.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, October 16, 2008 11:54 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Reading from device dependent region in PCI Config space?
well, if you knew the architecture of how bus interface std worked, you would already know the answer.
I know it - don’t worry about that…
the bus driver (pci.sys) is the one that provides the callbacks via the PDO,
not the FDO who controls the resources. the interface is meant to be used by the FDO driver,
not someone outside of the stack.
Hold on - let’s decide what we are speaking about. I am not saying that one should query PDO itself - instead, you would normally forward the query to the top of the stack. Consider the scenario when there is a filter above FDO, and, for this or that reason, it wants to make use of these callbacks(I know that normally you would expect such filter to be below FDO, but technically there is no reason why upper filter may not want to do it). Therefore, if FDO makes use of a given interface it would be quite unwise for it to pass the results of the query right to the caller for the reasons that you have described in your earlier post - instead, it would rather make sense to encapsulate them in FDOs handlers that would take care of these issues, and forward the request to the bus driver . After all, FDOs and filters may optionally handle IRP_MN_QUERY_INTERFACE, although, unlike bus drivers they are not required to do so…
Therefore, I would say that if the issue that you have described arise, it is FDOs, rather than caller’s, fault…
Anton Bassov
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer